7 ms·

This whole image, to me, represents a big problem with software engineering today: https://twitter.com/dankohn1/status/989956137603747840 https://twitter.com/da

• ramblerman 8y ago
  That you both have your domains of knowledge? I mean should the electrical engineer worry that you know what a socket is but not how it actually travels over the wire?
  • Vendan 8y ago
    Manchester encoding? (assuming twisted pair ethernet, at least last time I looked into this stuff). And no, while I don't expect a developer to be able to build a NIC from first principles, I do expect someone writing a distributed application to at least know the difference between TCP and UDP. (cause that's actually HIGHLY relevant).
  • hliyan 8y ago
    Actually, the correct analogy here is an electrical engineer who knows the the General Electric Foobar technology and can use its console to design and build an electrical system, while another engineer knows the Alacatel FizzBuzz technology and believes its superior because it can build larger systems. Neither truly understands how resistance or current actually works, because they're all abstracted away under system specific terminologies.
• tananaev 8y ago
  I have a mixed feeling about this. On one hand I definitely agree that it's good to know lower level technologies and that's something I always ask people in the interviews. I think it's important because I know it. On the other hand there is no end on how low you can go in the technology stack. Do you need to know how sockets works underneath? Low level network protocols? Do you need to know how hardware works because it probably influenced decisions that were made on the low level of the software stack? I know what socket is, but maybe the only reason I know it is because I'm old and I started coding at the time when raw sockets was the only way to implement network communication. When we have modern libraries and frameworks do we really need low level knowledge?
  • muxator 8y ago
    My personal advice in this cases is: try to be familiar with (at least) the abstraction layers below and above you. Are you a storage expert? Do not ignore how storage hardware is designed (even on a historical perspective) and frequently think about the system calls it is your responsibility to implement. Are you developing a sidecar proxy? Be fluent in low level network programming, and be aware of the interface you are offering to the application. Are you a manager? Focus on your own manager and objectives, but do not forget to empathically look at your team members.
    • pas 8y ago
      There are specialist subfields of programming nowadays: frontend, mobile app, embedded/microcontroller. And a frontend sitebuilder doesen't have to know anything about transistors, FinFET, system calls, and only the most curious would know about reflow and painting calls in a browser's rendering engine. Sure, the quest for performance always pushes people toward the metal, but from a website's perspective that's just the browser, and maybe TCP window tuning. (And sometimes someone finds that DNS was slow, but sometimes it was a bad BGP constellation, and there was nothing to do really. Or maybe the load balancer - or the backend - was overloaded because there was mutex contention in the kernel - or in the DB behind the backend, but that's again rather far from the usual sphere of investigation for "Frontend Engineers".) The imporant point would be to be able to go deeper, if there's a need. Or go higher, more abstract. That's engineering (or software design), recognizing, analyzing, and solving problems. I can't really blame the people who get by just knowing parts of AWS. They make great money by being a Cloud Consultant. It simply shows the low hanging fruits on the market. And how bad the demand side is when it comes to picking the experts.
      • pulsarpietro 8y ago
        > And how bad the demand side is when it comes to picking the experts. You meant, there is a very strong demand ?
        • pas 8y ago
• manigandham 8y ago
  Yes, there should be a baseline of understanding. It's unpopular to say but this field has too much complaining about things not being "easy enough" because of a lack of understanding concepts and architecture with too much focus on products, like you describe. Would you complain that you can't be a doctor without significant training or a lawyer without understanding the law? At some point, knowledge is required. Distributed applications require certain primitives and those can either be provided by Kubernetes or built from scratch, but they need to be understood to be used. There's no shortcut to that.
  • hliyan 8y ago
    Not sure exactly what you're trying to say, but it seems like your second paragraph skillfully refutes the points you seem to be making in your first and third.
    • manigandham 8y ago
      You need a real understanding of the problem and possible solutions to actually solve something. Tools (regardless of complexity) only help you solve it once you understand. People tend to say Kubernetes is complicated because they don't understand the problems it's solving in the first place. If they did, it would be rather straightforward or they would recognize they don't need it in the first place.
      • hliyan 8y ago
        Actually, my point was not that Kubernetes (and other "technologies" like it) is complicated, but that people tend to make it a be all and end all without actually understanding how it works under the hood. You're right about one thing: I've seen plenty of people proposing Kubernetes (or Docker Swarm or whatever) for simple systems that clearly don't need it.
        • gaius 8y ago
          I've seen plenty of people proposing Kubernetes (or Docker Swarm or whatever) for simple systems that clearly don't need it. That may be deliberate resume-padding. Same as most Hadoop implementations.
• gaius 8y ago
  I don't know what to think when I meet engineers who know how to setup an ELB on AWS but don't quite understand what a socket is... I keep meeting people who list say Postgres as a skill and when probed they admit they just clicked a button in Amazon RDS and that’s all they know about it. At some point it crosses the line into outright deception. This is the other side of the coin on why interviewing is so broken too.
  • carlmr 8y ago
    I'd say this goes both ways. You have companies asking for the impossible that won't interview you otherwise, this will create an incentive to deceive. I'd say HR is at fault here for asking for 10 years experience in everything, instead of just looking for software engineers that have good fundamentals and can learn. I once applied for a job writing tools for embedded programmers that said they want experience in Angular, React, SPAs whatever. I'm working in embedded systems, so obviously 99.9% of people haven't even touched web apps, never mind the modern technologies. I actually got to the interview (despite no deception), because I knew someone working there. They said they actually don't have a single web app and are doing everything in C# (on desktop), and were thinking about making some web apps. They still don't have any web apps.
    • gaius 8y ago
      I am pretty OK with a little subjective exaggeration, like if someone is at least competent/proficient and describes themselves as “expert”... well, who’s to say? But spending literally 2 minutes clicking a GUI then adding another skill to your CV is breathtaking audacity.
• pavlov 8y ago
  The overemphasis on products is a real problem because it makes the industry so susceptible to marketing snake-oil. Who would trust a doctor who proclaims his expertise in terms of brand names: "I've got ten years of experience in Cipro and Amoxil. Lately I've been prescribing Zithromax too! It's exciting to write that big Z. I really like Pfizer's community, their Slack is so helpful."
  • zachlatta 8y ago
    We trust surgeons who proclaim expertise in specific named procedures. Whether we like it or not, software engineering is becoming a trade. Trades aren't inherently low skill or high skill.
    • hliyan 8y ago
      Who are also heavily trained in the physiology of the organs they operate on, long before they're allowed anywhere near a scalpel. What you say about trades is true, but then we need to start making the distinction between software engineers and software technicians. I doubt that will go down well in an industry where everyone wants to be a senior software engineer, a tech lead or higher...
      • bryanrasmussen 8y ago
        I'm thinking the physiology of the organs might be less complicated than understanding a modern applications at all levels of the stack. Maybe that would be understanding the organs, the underlying physical processes those organs regulate, the chemicals that are released as parts of those processes, and the effects and composition of those chemicals, and if it is possible to induce similar effects through replacement chemicals in the way of medication.
        • ghthor 8y ago
          I'd say the complexity is quite similar, but that technology is more well defined then biology. Each area can still be segmented into to layers of understanding. For instance I have very little experience with machine level programming, but I have a general idea abiut how the disk, ram, cpu and cache are connected. Enough information to design fast programs, but not enough to re engineer that layer myself. Above that layer I am well experienced all the way to configuring high level software packages. Below that layer, circuit design maybe, I am basically in the dark. Biology is not much different, though there schooling seems to do a better job at exposing the student to all the layers we know about.
• robmcm 8y ago
  I expect people said this about developers that just knew about TCP/IP and not how the PHY worked. At every level of abstraction they is a boundary that people may not choose (or have time) to pass. I'm not saying everyone should be forced to learn about every layer, but these knowledge boundaries exist everywhere, and I'm not sure what can be done to improve the situation...
  • pas 8y ago
    There's no problem with not knowing the deeper/higher layers. The problem is when someone outright ignores their ignorance, when someone doesn't even acknowledge their boundaries. And when those boundaries are set in stone. ("I won't touch the terminal." or "I won't touch C." or "I won't touch CSS.")
• pulsarpietro 8y ago
  You are soo right ! There is a shift going on between "operators" and "engineer", many "software engineering" jobs mainly configure and operate on the top of somebody's else product. They do write code but the technical job, per-se, is not that skilled.
• zekrioca 8y ago
  "Full-stackoverflow" engineers
• dominotw 8y ago
  I don't know man ppl work to make money and feed and their family( mostly). 'Expert in sockets' is not something on the resume that would get them a job.
• dankohn1 8y ago
  You referenced my tweet of the latest Cloud Native Landscape, which is the backside of our handouts. Please don't miss the Cloud Native Trail Map, which is the front side: https://twitter.com/dankohn1/status/999727252135972864 https://twitter.com/dankohn1/status/999727252135972864
• falcolas 8y ago
  I'm late to this party, but I agree. We hired someone who was explicitly a "Kubernetes" expert, because we were investigating Kubernetes. What we discovered is that this meant they understood kubectl pretty well, and could write the yaml files. He didn't understand anything under the hood, so we had to re-discover everything. And, ultimately, if you want to get a feel for how complex k8s really is, try and use their documentation beyond the very basics. It's contradictory, incomplete, and behind by a version of two sometimes. It was fun building a set of automated interactions with kubectl and its cousins from the web documentation, only to find it doesn't work because the actual binaries expect different arguments. Or the API libraries if you're feeling particularly brave: a set of these horribly complex, dynamically generated files. Oh, some of them will be alpha, others beta, others beta2, etc. The version depends on the function you're using. Have fun!
• eternalban 8y ago
  Did you catch some of the comments yesterday (in the thread about Intel and age discrimination) poo-pooing the relevance of experience in software engineering? There is your answer, right there.
• sporkland 8y ago
  As someone that has stared at a number of those projects, at this point I'm pretty excited that there are a number of different alternatives which tweak different knobs in the solution space of the problem. I think in the next few years you'll see a winnowing of choices in each category, and problem bundling of the top tier choices into an effective PaaS solution. Kube is very clearly in the expansion phase of its lifecycle but I doubt it will stay this way over the long run. Additionally, I think the fact that the overall categories are pretty well chosen is a sign of how decently understood the macro problems are and that there's a good reason to hope that you'll end in a place with 1-2 dominant players in each.
• jgr447 8y ago
  Looking distractly it seems one of those "hot new javascript frameworks of the month" infographics.
• jgr447 8y ago
  Before rdbms became a commodity, companies would build them in house and required very specialized skills. Then it became a commodity and now you can just use postgresql for a basic web app without knowing much about dbs. Start adding scale and availability requirements in the mix, and you're back in need of specialized knowledge on indices, query planning, disk access patterns and db admin in general. Same for cloud providers imho: you can throw an app online quicker than ever before, but as things get more complex you will still need an understanding of infrastructure, network, availability, security etc.