5 ms·
This is not true at all. Most of the great first SRE were systems engineers (this is how Amazon used to call SREs) who understood the entire stack from the UI d
by StreamBright 10y ago
This is not true at all. Most of the great first SRE were systems engineers (this is how Amazon used to call SREs) who understood the entire stack from the UI down the the network packet and OS kernel level. Most software engineers do not have serious networking or operating system knowledge. On the top of that, there is a reason why performance engineers are so rare, understanding the complex computing systems we have is not an easy task. System administrators are able to configure your services but not necessarily know all the details of the operating system and file systems that is required to be an SRE. I think you are trying to oversimplify this subject quite a bit.
- jacquesm 10y ago> Most of the great first SRE were systems engineers (this is how Amazon used to call SREs) who understood the entire stack from the UI down the the network packet and OS kernel level. Aka the 'full stack developer' as opposed to the 'full stack developer' that knows both JavaScript, PHP and how to install the base distribution of CentOS.
- metaphorm 10y agoyou're commenting on sloppy use of language. you're right, we do tend to abbreviate and exclude relevant descriptive words. the "full stack developer" that knows both JavasScript and PHP (or whatever), and probably some database stuff, and how to config a HTTP server, and a few other bits of web odds and ends is really a "full stack web application developer". usually there is enough context to know if "web application" has been abbreviated out of the term though. as for the other kind of "full stack developer", the legendary creature that is equally comfortable doing UI scripting and Linux Kernel hacking...well personally I've never met one. mythical beast in my experience.
- throwaway2016a 10y ago> Most software engineers do not have serious networking or operating system knowledge. Anecdotally, this seems wrong but may actually be sadly right. I don't know how you can get through a decent Computer Science program without knowing these things. Although, I acknowledge quality in CS programs vary hugely. We had to write an Operating System (with basic memory and process management), know the OSI model up and down, and be able to deep dive into TCP/IP and UDP packets. In addition to coding and math. I'm actually pro software "engineer" but perhaps we should draw the line somewhere on a bare minimum of skills required. Probably about the line of an ABET accredited undergraduate BS in CS degree?
- StreamBright 10y agoI can speak of based on the ~100 interviews I conducted hiring SDEs. There are very few who could pass an SRE I/II interview, yet I know of few.
- dmoy 10y agoWhat's the pass/fail rate for sde though? If you interview 100 and 10 pass through to sde, and 2 of those could do sre, that's not actually that bad.
- pzh 10y agoWhy are people surprised? Taking all the coursework in Math, Programming, Algorithms, Operating Systems, Computer Networks, Security and Cryptography, Distributed Systems, Databases, etc., and also learning and internalizing all that knowledge is a significant time investment. Yet many people here would be offended at the idea that you can't be a proper engineer without a CS degree, and would insist that all you need is a three-month JS/Angular bootcamp and then you're golden. A formal CS degree in itself may not be a requirement, but the time investment in acquiring the knowledge sure is.
- Sean1708 10y agoBecause Bachelor's degrees don't give you a serious knowledge of or experience in anything, they give you shallow knowledge of and experience in a broad array of topics.
- snowwrestler 10y agoThis is just not true. Engineers in many disciplines other than CS (mechanical, electrical, civil, etc) begin serious professional work with only a bachelors degree.
- throwaway2016a 10y ago> other than CS This is simply not true as well. CS majors also can begin serious work with just a BS degree. I have no idea what school(s) the parent topic is refering to but remind me not to recommend people go there... Four years is a LOT of time to get deep on multiple CS topics not just a broad overview. If you finish 4 years of serious study and don't have deep knowledge of a few things you did college wrong. College is the only time in your adult life where your only job is to learn. It is incredible that many of us get that opportunity and that some people come out of it with just broad knowledge is disappointing. In my CS program, senior and most of junior year were almost entirely specialized courses where we had a choice to pick a topic that interests us and deep dive. (AI, graphics, networking, bioinformatics, big data, programming language theory, etc). All the general studies were mostly done by the end of sophomore year.
- samfisher83 10y agoIf you take comp sci you are required to take a class in os and networking. I think many swe are cs majors.
- StreamBright 10y agoYes, and those classes teaches you the theory while when you are working for companies you need to know the practical side of things. In our country even the theory is lagged behind the practical usage by 5-10 years. Funnily enough most the senior SREs I know do not have any formal education in CS (anecdotal evidence).
- graycat 10y ago> reason why performance engineers are so rare, understanding the complex computing systems we have is not an easy task. At times it has been possible to make some progress on the complexity by regarding each application, virtual machine, server, server cluster, or server farm as a network of queues and apply queuing theory and/or Monte Carlo simulation. In addition some of the old work in optimization under uncertainty likely applies.
- srean 10y agoHave you looked at stochastic network calculus ? Network of queues can become hrrendoulsy difficult to analyze unless one assumes memoryless arrivals etc etc. Network calculus and stochastic network calculus simplifies things a great deal by going after bounds rather than exact answers. You might like it
- graycat 10y agoI never heard of "Network calculus and stochastic network calculus". Certainly no such topics were in any of the applied math grad courses I took. For "going after bounds rather than exact answers", for analyzing network performance, there is a hugely simplifying approach: Just look at the bottlenecks and largely f'get about the rest; maybe that is related to what you mentioned. For network queuing, really I was suggesting using that as a paradigm to formulate an analysis; I accept that analytic solutions are unpromising -- more generally, the exact probabilistic calculations out of queuing theory research are complicated even for simple cases. So, for solutions, i.e., actionable information, use Monte Carlo. Once I knew a guy at IBM's Watson lab who was big on such things. There was a claim that at one time his work was useful in designing some of an IBM mainframe I/O subsystem. He had some software that I used once. His software wanted to collect the usual descriptive statistics, but I wanted the sample paths from the Monte Carlo, got those, and did more analysis of those.
- srean 10y ago> I never heard of "Network calculus and stochastic network calculus". ...and now you have :) > Certainly no such topics were in any of the applied math grad courses I took. Yeah they are a newer development. Stochastic network calculus more so. Network calculus is older, it even has a wikipedia page https://en.wikipedia.org/wiki/Network_calculus https://en.wikipedia.org/wiki/Network_calculus A key idea is convolution but in the max-plus algebra and martingale large deviations. > For network queuing, really I was suggesting using that as a paradigm to formulate an analysis; Indeed. SNCs can be a helpful tool there. Yes they are bounds, but a lot of progress has been made to make them tight https://arxiv.org/pdf/1303.4114.pdf https://arxiv.org/pdf/1303.4114.pdf they arent quite there yet numerically but tight enough to give an intuition. NC bounds are a lot looser.