Comments by "" (@JinnGuild) on "Latency LESS THAN 0.000001 Seconds For Cloud Computing" video.

@giovani5586 I can understand that as some people's viewpoint, which is why I said it depends on what your ratio is. But to me, I'd rephrase your statement to something like this: Operations, Planning, Security, Reliability Engineering, Data Architecture, User Experience, Quality Engineering, Software Engineering (etc etc) are all *Information Technology* subjects. Quality Engineering is not Software Engineering, though they are two disciplines that work together. IT Operations is not Software Engineering, though it is required for Software to run. Site Reliability is not Software Engineering, though it is the latest role for companies following best practices. etc etc As a 20 year Software Engineer (and "Developer" before that), I could fill multiple full time [jobs, roles, contracts] purely focusing on the principles and practices that elevate Software Development into an Engineering mindset. TLDR; How do we write code to do this thing vs. Why do we write code to do this thing. In the context of this video (and Cloud Computing) which is an Operations/SRE concern, Software Engineering is absolutely required. Because (Purely in relation to code) we need to make choices on how we abstract our work, how we decouple different parts of the system, build stateless systems, make sure we aren't building "Distributed Monoliths", and all kinds of Code related concerns. So I can see some argument or some ratio toward including those other *Information Technology* roles and conflating them with "Software Engineering", but I personally set my ratio to a "Software Engineer" focusing on Operations and hardware like 10% simply to overlap with those roles in a DevOps mentality, and maybe 50% focused on coding, and plenty more room for other things not discussed here.
2
@jasondbaker I've noticed some of that. For example, I haven't seen truly effective "QA" Departments for quite a long time. As companies "Shift Left", the checks for quality (including testing) becomes automated and run by scripts/code. They usually grow from GREAT QA personnel who learn a bit of coding. But those people still fall under their own teams. Perhaps renamed "Quality Engineering", definitely Site Reliability Engineering, but not Software Engineering.
1
 @ContinuousDelivery Thanks for the link! I'm headed over to watch that whole thing now.
1
@ContinuousDelivery Yes indeed. I agree, and that scenario shows how things can vary. I did say a couple times that each person will have a different ratio in their definition of "Software Engineering", which includes how much they lean toward the Code side, versus how much they overlap with Process, Design, Infra, etc. I'm sure in some companies, Software Engineers purely do code, while in others, Software Engineer is defined such that code isn't even on their mind, and everything between.
1
@ContinuousDelivery I do personally bias toward Software Engineering leaning fairly heavily toward code, but I'm only calling it a hat. I do believe that somebody can both wear the hat of Software Engineer (from a code-design perspective), as well as having fairly extreme coordination or fully hat-wearing of some more traditional infrastructure, testing, or planning roles. Just like I believe somebody can both build and operate a database as well as design and code a Website and everything between. That doesn't mean that we title that person a DBA and say DBAs do Web Design. It's just a talented person who can wear many hats. And though I do enjoy having clear definitions of roles, that doesn't mean I think they need to be separated. I 100% think there is overlap, coordination and communication, and a required understanding between the roles and the people who fulfill them.
1
@ContinuousDelivery Absolutely, and my conversation here seems harsh and out of place given that this video has a very clean start and end, the first paragraph in the description doesn't say it's just a clip of a longer video, I'm new to your channel, and I do have a weakness of not scrolling down to links in descriptions since they are almost always ads or ref material and such. Those things combined (especially my weakness) made me have a strong desire for more than the given content, and made me converse on there needing to be more than Zero talk about code as seen here. I'm watching the other video now. I do hope to continue to discuss and hopefully have some solid back and forth with you about Software Engineering as I watch more of your content! Loving it all so far.
1