“Software engineering” in practice is 90% about keeping your stuff organized well enough that you and others can comprehend it, make sure it does what it intends, and use and and extend it. That extends to making project plans to begin with, and any documentation.
I took a course in Software Engineering as part of my CS degree.
As part of that course, we simulated spec work by having Team A write the specifications for a project and having Team B trying to interpret that as loosely as possible while still being compliant. (Team C would then do that with Team B's spec and so on, so there would be no 'revenge').
That wasn't perfect, but it did teach us a lot about writing down implicit and non-functional requirements, as well as the use of precise language.
When I did CS (my alma mater didn't have Software engineering at the time,) many courses did similar but with a different spin; The work based on the exercise was pre-divided into modules that were fairly similar in size. And at the end you had to code your module and everything had to 'work together'.
As a blunt observation, the courses where writing a specification was part of the project everything seemed to click together more easily. The ones where a specification wasn't written were the ones where people were scrambling on due date.
As a non-CS engineer who writes software for a living, I can definitely say that there are times that I wish I had formal training in algorithms, parallel data structures, compilers, operating systems and hardware. There are many times that I need to rewrite my code because of non-adequate design. Other times I reach corner cases that take me too long to debug, only to realize much later that there was a lower-level explanation for the unexpected behavior.
Congratulations! By not dismissing these temporary setbacks as being just the way things are, you have the right attitude to become even more successful at what you do.
There seems to be lots of information, of the sort you are interested in, available on the internet (I won't recommend anything specific as there is too much!) One can learn a lot simply by digging deeper into the specific issues that one has encountered, especially as you begin to see the links between them.
> There seems to be lots of information, of the sort you are interested in, available on the internet (I won't recommend anything specific as there is too much!)
As a non-CS developer, I find this us not an easy problem to overcome: the wide availability of resources of varying quality.
I work more than full time (US exempt employee), and I have enough knowledge that intermediate depth and quality resources do not provide enough and, not having a solid grasp of fundamentals, MIT's SICP course is a bit beyond my current grasp,
I would love recommendations for a series of courses, a series of syllabuses, or even a part-time degree program where I could meaningfully progress while working full time.
I'm not afraid of advanced math, I'm ignorant but willing to learn about data structures. I'm highly educable but I'm time-poor.
What targeted resources would be a good investment of my limited time?
My “one weird trick” is take the time to understand type theory.
How are types implemented?
What are the native types on your computer?
How do types and whiteboard diagrams relate?
If you can answer those questions, you’ll start to get an intuitive sense of how to make a program out of types (eg, domain driven design) and of how the computer will interpret those types.
I graduated with a CS degree and a minor in Web Services and Applications. Let me tell you that whilst those topics are useful, they were pretty tailored and if I'm being 100% honest, I don't even recall the majority of them.
My day to day job is piping APIs together and making sure we deliver features on time.
On the rare occasion that I need to use a data structure or an algorithm to optimize for Time Space complexity, I'll either use a community built package or a language level feature. I'll never invent my own because whatever I come up with will be half baked anyway.
Knowing all the above is useful for passing interviews but not much use in your everyday life unless you are doing something other than SWE such as R&D or data science.
>> if I'm being 100% honest, I don't even recall the majority of them.
100% this. A lot of these concepts go over your head if you haven't seen a practical application for them. By the time you've encountered such a use in industry, the knowledge is long forgotten.
Yes, but the point of memorisation is you can much quicker re-learn the subject and you know there is a solution to a problem when you face it. If you have never learnt it, you don't know that there is a solution, or you start to optimise things in a way that is proven to be wrong. You might not able to recall them, but the knowledge is likely there in your subconscious.
> On the rare occasion that I need to use a data structure or an algorithm to optimize for Time Space complexity, I'll either use a community built package or a language level feature. I'll never invent my own because whatever I come up with will be half baked anyway.
In these cases you recognized you needed to use a specific algorithm or data structure and was aware of it's existence, name and properties. That's most of the work.
Contrast this with code where common data structures are re-implemented (I need a dictionary and all I know is an array, better iterate and compare the keys until I find the right thing). And that's only scratching the surface of bad code, believe me.
> There are many times that I need to rewrite my code because of non-adequate design.
Formal education won't give you the knowledge to get it right every single time. Your design will be always non-adequate because the circumstances always change.
The knowledge body of a CS and engineering can be obtained without enrolling these days. Engineering is about problem solving within the resource constrains and to a specification. Getting the specification right and fitting in the resource constrains are the biggest challenges that only experience will prepare for, because these are domain-specific.
CS and engineering studies can give you a toolkit to solve some problems and helps to give you to develop a "gut instinct" to pick a solution.
This happened to me (math background, now write software), so I decided to fix it : I read most of the classic textbooks over the course of a few years, and tried to apply what I learned in them at my day job (provided that it was useful to my company obviously).
Three things happened :
- I got a lot better at my job because my toolbox was a lot bigger
- I developed a much 'broader' view of the field, which became unified instead of a collection of subfields
- I realized that there was even more that I didn't know about, and that I should keep reading !
That’s funny. I completely agree, but at work lately I’ve come up against a religious fanaticism level of DRY and “we created an algorithm to match all these things”.
Great, you spent two weeks saving two percent of compute time and now only two people will ever be able to change this code. WTF?
That is a perspective one acquires after a while. Another huge part is having the knowledge required to not blunder. The questions a beginner SE might ask are along the lines of "what are pipes? how do you package something to release it? how do I revert a git commit? how do i exit vim?". I know many people who are completing degrees in CS and related fields that do not know the answer to these questions.
That said, I think the best way to learn these kind of things is on the job, if you find a company kind enough to let you practice the basics.
I'd say it's less to do with kindness and more along the lines of a VC who invests in a hand full of startups. If you train a certain amount of beginners, you'll likely turn out a few high value engineers. A few really strong engineers could produce sufficient business value that they offset the 'loss' for the ones that don't really make the cut.
> If you have a choice between a comp sci and a software engineering career, go for comp sci. One prepares you for a wide swath of careers, the other gives you tools for today.
This advice probably depends heavily upon the school. At mine, a Software Engineering degree required the same classes as Computer Science, but with extra engineering ones on top.
Is math science? Science is generally about testability, right? If math isn't science, it's still extremely useful, and a valid, rigorous field in itself. I don't think it's so easy though. If anything, it seems like in software engineering, you come up with a "model" of how it ought to be done, and then see if that actually works in the real world. Food for thought :D
Why do you think Math is not testable? You can run numerical experiments to validate laws, theorems etc Heck we even have numerically supported proofs nowadays
Scientific hypothesis need to be verifiable and falsifiable. Most hypothesis that follow them are sciences. Mathematics is one of them and so are many others.
The thing that really distinguishes science is an appeal to empirical evidence as a boundary condition for the development and acceptance of hypotheses. Science can get lost in the woods for a long time -- for one thing, theory is fun -- but eventually has to bump into some empirical data. For instance the trouble that plagues the search for a theory that reconciles gravity and quantum mechanics is that theories are a dime a dozen, but ones that can be empirically tested remain elusive.
Theology was regarded as a science in the middle ages, but its appeal was to evidence found in scripture and tradition rather than empirical data. I honestly don't know if it's regarded in the same way today.
With that said, scientific methodology can be useful in the exploration of math. I've used computation to guide me towards a proof. For instance if the problem is: "Find all numbers such that ...," and the first 10 of those numbers are powers of two, hmmmm... guess where you'll start looking for a proof. But the computation itself was not a proof.
Computers can be studied from a pure math angle, e.g., computing the order of a sorting algorithm. But they can also be studied by treating a computer as an unknown whose properties are discovered by empirical testing of hypotheses. For instance, benchmarking is such a pursuit.
In English, science (other colloquially, as in "the science of fashionology") means something specific -- a discipline whose core technique of knowledge discovery is the Scientific Method. That is, in English, math is not a science.
Given this: in what universe is Computer Science a science? The Scientific Method is used here and there, of course, but it's hardly the core technique.
Software Engineering is badly named. Real engineers build artifacts that are designed to meet performance requirements as efficiently as possible. Software people can't even effectively specify the performance requirements of the artifacts that they produce.
That's mostly because the performance requirements don't exist, certainly not in the same sense as they do for mechanical engineering.
Imagine someone designing and constructing a bridge, and right after it was possible to walk gingerly across one part of it, the people in charge of the project said "hmm, could you put a parking area in the middle?". And then, right after you had done that, came back and said "great, but we'd like to make the whole thing a double decker so we can run a train line across the lower level?". Miraculously, you pull this off, and then they announce that they've realized that the bridge needs to open in the middle to allow large boats through.
We (generally) do not allow engineering projects rooted in the physical world to have fluid specifications, because of the cost and complexity of doing so.
Although there is a real cost and huge complexity to allowing software engineering to accomodate goal flexibility as much as we do, it is vastly less than would be the case for most mechanical and chemical engineering projects.
And the reality is that human goals do change as exposure to a project takes place. There are probably many people involved in bridge specifications who wish they could have gone back and significantly altered some part of the design, based on things learned during construction and early use. But we don't allow that, and so we're left with an impression that only non-software engineers are good at handling performance specifications. It's not true.
In the US, you can do engineering work without having a PE, no licensing required, and any degree requirements are usually imposed by the company not regulations. There are only some things that require a PE.
Source: I studied EE, did not get a PE or any sort of license beyond my degree, and worked in defense, and commercial engineering jobs
I've seen this sentiment raised in several conference talks but the follow-on question of "how do we achieve this in software development?" is one where nobody really has a good answer. The story is that many civil engineers, while taking undergrad classes, had to look at, hold, and pass around a piece of the Tacoma Narrows bridge that had failed and collapsed. There is a story that some Boeing engineers kept on their desk a part from a plane that suffered structural failure (and cost the lives of dozens of people) to remind them of the stakes involved if they weren't sufficiently disciplined in their job.
In the realm of software engineering I don't know that we've had a catastrophic failure where the infrastructure costs of repair were in the billions or there was tangible loss of life. The biggest example that comes to mind was the explosion of the Ariane rocket because the software caused the rocket to rotate in the wrong direction so the ground-controllers executed a self-destruct... maybe pieces of a Tesla that crashed while on auto-pilot would be a candidate for physical objects we can hold in our hands to remind us that software bugs can kill?
$1B is a high bar, but there are probably examples. Another comment mentions MCAS, but maybe that's too easily classified as a management failure. Out of curiosity I looked up a couple of other contenders, but neither made the cut.
However, that search took me to an example that I didn't recall, resulting in loss of life. I'll probably reference this story about the Therac-25 in the future as it hits on a number of clear software engineering failures:
> In the realm of software engineering I don't know that we've had a catastrophic failure where the infrastructure costs of repair were in the billions or there was tangible loss of life.
The multi-day 2003 blackout in the Northeast US states and Ontario, Canada qualifies in terms of impact (many billions of $). It was a systemic flaw with a software bug as a proximate cause. I think most major failures with high impact in a software-intensive system will sort of look similar: a software fault that cascades to the real world.
Most of my career has been as a "software engineer" in aerospace. We absolutely do build things to requirements, and verify those requirements are met, with copious amounts of formal process.
This same style of development could be applied to any software development venture, but it's usually not, because most software doesn't benefit from it enough to warrant the extra time and expense.
If you are asking me personally, my verification experience has been a mixture of manual tests, and writing test scripts in either Python or a custom in-house language. These scripts run in an avionics simulation environment, in which typically there is one avionics component under test, which is running either a desktop build of its code, or running as the actual hardware unit, attached to a desktop via Ethernet or ARINC 429 connections. The other avionics components are then either simulated, or, as needed, running actual code.
(The majority of my avionics work has actually been directly working on such simulation systems, building and certifying them for formal verification use, but I have done some verification work on avionics boxes as well.)
Outside of my personal experience, I am aware of projects using things like TLA+. I suspect that is more common the higher up you go in system criticality. Even within avionics, not every system requires the same level of scrutiny... for example, you need to more exhaustively test a flight controls system than a flight management system.
In any case, the FAA does not dictate particular tools. They dictate a level of quality that any tools used must adhere to (the tools themselves must be certified based on how they are used), but otherwise a project is welcome to use whatever tools they wish. Or, no tools.
Amusingly, the engineers I work with have a saying, which is: "This is not aerospace," meaning that they will not apply formal engineering methods in their design processes.
> Software people can't even effectively specify the performance requirements of the artifacts that they produce.
This is Real Scottsman nonsense. Algorithms can be easily tested, and can be modified and optimized to meet a host of requirements, from computational complexity to real-world efficiency to fairness to privacy. We specify the performance requirements of software all the time.
Agreed. There is Computer Science, Software Engineering, and then Application Programming. SW engineers work in OSs, drivers, firmware, and applied areas likes comms and robotics, where "move fast and break things" isn't the theme, at all. App programmers use established and trendy 'stacks', and are often superficially knowledgeable of the details of the underlying tech -- and there's nothing at all wrong with that. I estimate that 90% of people writing code are App programmers.
> SW engineers work in OSs, drivers, firmware, and applied areas likes comms and robotics
That would be system programming, part of computer engineering actually [1], not software engineering. Also software engineering usually does include some computer engineering.
Sometimes you can use technology without having to understand it. You can use put together a solution using HTTP without having to understand the entire protocol stack under it. You can create some small service using an scripting language without having to learn algorithms or data structures, memory management, multi-threading, etc.
But when things do not work, and you are required to do retrospectives and post-mortems detailing why things break, and when you are required to mitigate risks from things breaking again... that's when you can no longer get away with simply seeing yourself as a someone abstracted from the low-level stuff. You will now have to understand things, and if you don't, your organization will find someone else that will.
You’d think that’d be the case, but many of the post-mortems are pretty high level too. Most SEs don’t know HTTP from top to bottom. And they’re mostly fine.
Post-mortems start being important when users rely on your stuff and stakeholders want an explanation for a problem. They also want to understand if you understand the problem, if you care about the problem, and how is it not going to happen again.
If you say "we fixed the issue" 10 times in a row for the same issue, you lose credibility and the organization will look to replace you.
If a problem in your product is affecting my ability to do business, you either give me a proper explanation or I will find a replacement product.
The prototyping phase of a product is just an engineering honeymoon, it does not last forever.
Software development is more like being a machinist. The bad ones just do what they're told, the good ones know what is possible, and the best ones know the principles as well as the practice.
A pure computer scientist is like the engineer that designs with SolidWorks and has never actually run a Bridgeport, or had to pop the access panels and grease bearings day-to-day.
I attended the same school as the author in Slovenia. The amount of math and theory was too much for me. One graduate of the university is a prof. of AI at Harvard, another one teaches graph theory at Berkeley, another one who thought me math is a prof. of AI in Toronto and director at Nvidia.
So I dropped out, went working for a few years, then enrolled at an another university, then went working again abroad. Now I'm preparing myself for my last exam and will write my Bachelor thesis in the first half of next year.
I plan to graduate, even if it's the last thing I do in life.
I think that overstates the difference. I think a better analogy is architects vs. construction workers. Any decent architect will have a pretty strong understanding of the realities of construction, and an experienced construction worker who has moved around through different trades could probably design a decent house. But you'd only trust a trained architect on bigger, more complex projects, and you'd want disciplined, experienced construction workers doing the work on anything that is meant to last.
Today cutting edge astronomy isn't that removed from telescope design. Understanding how the instrument works and it's limitations is pretty much essential to understand the data it produces.
One of the things that's interesting about modern languages like Java and Typescript is that they target software engineers that want things like generics, type safety, etc.
A lot of data scientists DO NOT want this. They're heavy on the science and less so on the software engineering.
I think this is one of the reasons Python took off.
Having to learn generics, type safety, exception handling, etc turns out to be a real pain when you're also learning about neural networks, AIs, etc.
This is also why languages such as R, F#, and many others have emerged. I’m most familiar with F#, so I’ll use it as my example, but it is built on .Net just like C# and VB. That means you not only get access to all of the features they offer, but in a functional language that doesn’t enforce any of them on you.
Microsoft was clearly going for a best of both worlds approach - .Net if you need it, just your data if you don’t. I find it a pain in the ass, but all the data guys at work love it because they can mix and match with our existing code and still do their own thing.
I’m still salty about this shift. No one really goes back and admits, “maybe we were all wrong.”
IMO, the best explanation is the high influx of new, young devs results in ideological conformity in lieu of developed aesthetics. This also explains the unnatural amount of sway by so-called “thought leaders.”
More complicated functionality has moved to integrations/APIs in the past 8 years.
When you’re trying to ship an extensive application and building out features that few customers may ever use, types absolutely slow you down. When you’re integrating with a 3rd-party API, you have two differences:
1. relatively high confidence the API won’t change much, which makes implementing typed code lower risk and higher ROI
2. a slower feedback loop over the “reload the page” of rolling your own, so types catching issues earlier than heavy integration tests is much more valuable
I use untyped Ruby/Rails code for all of the CRUD, and golang AWS lambdas for anything integrating with SDKs/APIs. Best of both worlds, in my experience.
I think one size doesn’t fit all. Some engineers like static types & some don’t. People who want it will work on adding it. I don’t think same people who disliked earlier changed their mind.
Absolutely. “Anyone can write JavaScript” led to that crap. It also led to having modules that do things like determine if a number is even or odd and get exploited.
Having tried TypeScript and Kotlin, TypeScript is like a half-assed type system that gives you cryptic error messages in compile time and mindfuck stack traces in run time.
Using assert(value, message?) function ends up being more useful and ergonomic.
I'll keep that in mind the next time I have to work around pandas automatically converting strings to floats. Or ints to floats (nope, no NaNs in either the inputs or the output). I'm sure it'll make me feel better about my data getting corrupted.
> I think this is one of the reasons Python took off.
Python took off for data because the frameworks and libraries around it. Without IPython/Jupyter, dataframes, Scipy, it would have way less marketshare.
As a physics prof, who teaches quantum computing, I have the opposite problem. At my university, the computer science degree is just a software engineering degree. Students barely learn any computer science fundamentals beyond those required to get a SE job. There are very good at the SE, no doubt, but I really wish the uni just called a spade a spade, and a a software engineering degree a BS software engineering.
It’s nice to hear someone “on the inside” say that.
I fully support offering degrees that train you for the practical aspects of software engineering without wasting time on things you’re unlikely to ever use in that field. At the same time, one of these things is not like the other, you can’t call them the same.
I wish I knew the difference when I started at university. In retrospect, It wouldn't have changed anything, because I love my time as an undergrad at my school. But, the perception of what a software engineer career looks like would have changed. At best, I would have advocated to my school of engineering to offer a software engineering degree.
Though, I imagine it is difficult for universities. They're trying to be more theoretical and less practical than trade schools, despite the majority of undergrads do not continue to pursue more degrees. I imagine if universities shifted its focus to more applied sciences, it might be even harder to keep the number of applications for masters and phd programs up.
Universities can offer a real computer science degree from the Science school, and a SE degree from the engineering department. Same way, Electrical Engineering degrees are not called BS Physics and Electromagnetism, and are separate from the Physics degree.
I doubt there will be any impact on MS/Phd applicants. The people who are interested in the fundamentals are usually interested from the start.
The students also get an education in history, philosophy, economics, policy, etc, that help them become more rounded individuals, and to some extent, engineers who understand the impact of their work on society a lot more.
While, I support trade schools for SE, they don't provide a "complete" education.
To my knowledge, it's only really the U.S and maybe Canada that do the whole rounded education thing. In the U.K, Ireland, and what I've seen on eunicas, the degree is focused on a single subject.
Oh we understand the professor and academia perspective, we also understand how that is divorced from reality.
Higher education was always for elitists that had the privilege and time to pursue "complete" education. Everyone else just got a job, they went to trade school or had an apprenticeship or just less specialized work. A lot of that kind of work - briefly in history and into the present - required having a degree. Software engineering is not one of those.
So don't get it twisted. People that want to pursue a complete education because they are interested in the subject can keep going to academia. For everyone else, it is a waste of time, software engineering trade schools are cheaper, faster and good enough.
I've encountered so many definitions of Computer Science and Software Engineering that I lost track. Every school seems to interpret the brief slightly differently.
Some school have Computer Science as a spin off of the mathematics department. You can graduate without writing a single line of code. As Knuth said in one of it's memos: "Beware of bugs in the above code; I have only proved it correct, not tried it."[0]
Others have Computer Science as a spinoff of EE (MIT and Berkley are like that) where CS is the skills you need once the circuits are reliable enough you don't have to care too much for their implementation.
Lastly, I've seen "Software Engineering" courses at some places that are almost trade-school-esque discipline (beware of some masters degrees [1]) that's basically what would have been called data processing or IT/Information System.
Other places consider it double major in CS and Engineering where there's dedicated courses on software design. As a rule of thumb, if the OS class is about mutex and semaphore you are at the right spot. If there's group policy involved, look at transferring.
>Lastly, I've seen "Software Engineering" courses at some places that are almost trade-school-esque discipline (beware of some masters degrees [1]) that's basically what would have been called data processing or IT/Information System.
At my institution, the Software Engineering students take the same courses as the Computer Science students. However, the SE program has less flexibility in electives, as nearly all of their electives have been replaced by mandatory engineering courses.
I do like the author's point about understanding vs knowledge. Often I see the industry and their evangelists recycling old ideas as the new shiny thing with t-shirts and conferences, and it can feel daunting to keep up.
The analogy I usually make is that theoretical physics has more or less nothing to do with mechanical engineering in much the same way that computer science has more or less nothing to do with writing software for a living.
In both cases, it isn't done to trust the theoreticians with power tools: or hold the guys in the shop responsible for the deep magic, either.
That duality is a few degree too far removed to map to CS->SE.
Alogrithms, & data structures are one of the obvious fully shared concerns between CS and SE.
Also, as a software practitioner, I can give you multiple examples of reaching into CS research and then directly appying it to code. A favorite ~recent example was discovering "Power of Two Choices" (for bins and balls) a few years ago, and then, that very day, doing a prototype of a cache using that approach. I seriously doubt a Mechanical Engineers would have the same experience with ~contemporary fundamental physics theoretical papers.
then punt the analogy back a century or so to a time when modern physics and it’s engineering equivalents were more in the same rough infancy that CS is in now. You’ll see a more equivalent cross-fertilization then, perhaps.
I don’t mean that as an insult, at all, just a recognition that as a field, CS is maybe 75 years old.
We're in agreement regarding the infancy of the field and how that manifests in practice.
I wouldn't take it as an insult, if I were a CS worker, however. That just means that the Gausses, Euclids, etc. of this field have yet to appear. All the warts of this field aside, it does offer a chance for making a dent in history. Something the young workers in the field may want to keep in mind ..
You're conflating a few things -- it's not like mechE's don't have their own journals in which to publish scientific papers, after all.
It's merely that, to pick some famous names: what leslie lamport or simon peyton-jones or donald knuth do with their daily professional lives and output has a passing similarity with what titus winters or linus torvalds or raymond chen or .. have, but not much more than that. And both groups know stuff the the other one does not.
I'm not entirely sure why there needs to be a hierarchy of degrees. There are many disciplines that can lead to careers in software, and IMO they all have different strengths and weaknesses. I come from a very traditional electrical engineering education(analog circuit design & electromagnetics) and those fundamentals have been invaluable in my software career.
This will vary a lot by institution. At my institution, the SE students are enrolled in all the CS courses, however they also have to take the core engineering courses as well. This leaves them with substantially less flexibility in electives, but a better understanding of the engineering and managerial aspects of SE.
Coming from CS background, I have realized that in terms of speed, my SE counterparts seems to do better. I need to think too much, long term works fine but depending on the requirements it can be a drawback. Example: new feature, customers ready to use it I'm thinking from performance, network, even support perspective and customer just waiting.
The real mindfuck is that people with plain Comp Sci qualifications think they are ready to be competent at software engineering, whether that is software at scale, high confidence in correctness, operations (systems programmers / SREs / DevOps) etc.
Can we recognize that your bachelor's degree is just a starting point, that leaves you fundamentally unqualified for many tasks, and you'll have learn (via painful experience, apprenticeship [if that is emotionally possible for Gen Y/Z], or self study) many things to become a journeyman software expert?
Do you need to understand the basics of algorithmic complexity? Yes. Do you need to be able to write a compiler? No. (It's useful, but unless it is your major, no, and you can learn it later.) I would trade off compiler design for a software configuration management course. Should you understand some crypto basics? Yes. But I'd rather employ someone who understands TLS and PKI than someone who has written a toy project to implement a cipher.
I don't think I've ever heard anyone claim otherwise. Someone with a bachelor's and no experience is only qualified for entry-level jobs, where they will generally be working under close supervision.
The sentiment I get from some people is that traditional, pure CS educations are in some way uniquely qualifing, and software eng subjects (config mgmt, project mgmt, requirements/design/V&V) are trade skills and paperwork that don't have rigour, whereas in reality they are foundational skills for big/complex software projects. It is as reductionist as saying CS is just programming.
> that leaves you fundamentally unqualified for many tasks, and you'll have learn (via painful experience, apprenticeship [if that is emotionally possible for Gen Y/Z], or self study) many things
This is not a generational thing. I know at least as many entitled older folks as I do detached younger folks.
Moreover, part of the drive for saving dying industries is because the folks in those industries don't want to pivot because that's hard.
Some people just want life to be easier and give in to that. It is easy to sympathize with that because life is hard and it would be nice.
I notice that compilers are often singled out (unfairly imo) in these discussions. I found the language theory + compilers sequence to be one of the most practically useful parts of the entire major. in two semesters, I went from helpless googling to actually understanding compiler errors. I'll concede that the typical "toy compiler" projects are maybe not the best use of time for someone who wants to be a software engineer, but understanding PDAs and context-free languages is super helpful when you don't have the luxury of using a friendly compiler. most of the value is front-loaded in language theory, but a compilers course really drives the concepts home.
And yet, these things are easily comprehensible facts without you needing to understand how to implement an LL1 parser.
More generally, I can always come up with something you can't understand without some specialised knowledge. I could argue that you couldn't possibly be a computer scientist / software engineer unless you understand the foundations of digital logic -- how else to understand safe implementation of crypto, caching and VM? Who cares about big O when people write pointer hungry code that faults to main memory every cycle?
I guess we might both be arguing for 'knowing what we don't know' and where to start looking.
You can parse HTML using regex. Not all HTML, but specific HTML pages are almost always regular as they typically have well formed nesting. It isn't a good idea but language theory doesn't say it is impossible.
Someone that can take something confusing they've written and then refactor it into something easy to read and modify is better than most compsci skills. Because that person can usually suffer through hours of googling to find a math solution to a problem.
Sure. But I've met too many young programmers who absolutely reject any attempt at guidance, build towers of fragile code, and just seem unable to ask for advice. They have a strong tendency to want to be in directly in charge of something, regardless of experience or aptitude for that. It has been very noticeable the last 10 years.
It took people too long to realize. CS and SE are completely different. The only thing in common is computers. CS is much more than computers and software though. It explores mechanized models of how universe or prats of it works and proves properties or investigates the value of different models. Part of this universe is software.
I've always thought computer science should just be in the math department. Software engineering uses concepts from CS but in my experience it's far apart.
122 comments
[ 3.1 ms ] story [ 175 ms ] threadThat’s hard to teach as a separate thing.
As part of that course, we simulated spec work by having Team A write the specifications for a project and having Team B trying to interpret that as loosely as possible while still being compliant. (Team C would then do that with Team B's spec and so on, so there would be no 'revenge').
That wasn't perfect, but it did teach us a lot about writing down implicit and non-functional requirements, as well as the use of precise language.
As a blunt observation, the courses where writing a specification was part of the project everything seemed to click together more easily. The ones where a specification wasn't written were the ones where people were scrambling on due date.
There seems to be lots of information, of the sort you are interested in, available on the internet (I won't recommend anything specific as there is too much!) One can learn a lot simply by digging deeper into the specific issues that one has encountered, especially as you begin to see the links between them.
As a non-CS developer, I find this us not an easy problem to overcome: the wide availability of resources of varying quality.
I work more than full time (US exempt employee), and I have enough knowledge that intermediate depth and quality resources do not provide enough and, not having a solid grasp of fundamentals, MIT's SICP course is a bit beyond my current grasp,
I would love recommendations for a series of courses, a series of syllabuses, or even a part-time degree program where I could meaningfully progress while working full time.
I'm not afraid of advanced math, I'm ignorant but willing to learn about data structures. I'm highly educable but I'm time-poor.
What targeted resources would be a good investment of my limited time?
How are types implemented?
What are the native types on your computer?
How do types and whiteboard diagrams relate?
If you can answer those questions, you’ll start to get an intuitive sense of how to make a program out of types (eg, domain driven design) and of how the computer will interpret those types.
My day to day job is piping APIs together and making sure we deliver features on time.
On the rare occasion that I need to use a data structure or an algorithm to optimize for Time Space complexity, I'll either use a community built package or a language level feature. I'll never invent my own because whatever I come up with will be half baked anyway.
Knowing all the above is useful for passing interviews but not much use in your everyday life unless you are doing something other than SWE such as R&D or data science.
Just my 2c.
100% this. A lot of these concepts go over your head if you haven't seen a practical application for them. By the time you've encountered such a use in industry, the knowledge is long forgotten.
In these cases you recognized you needed to use a specific algorithm or data structure and was aware of it's existence, name and properties. That's most of the work.
Contrast this with code where common data structures are re-implemented (I need a dictionary and all I know is an array, better iterate and compare the keys until I find the right thing). And that's only scratching the surface of bad code, believe me.
Formal education won't give you the knowledge to get it right every single time. Your design will be always non-adequate because the circumstances always change.
The knowledge body of a CS and engineering can be obtained without enrolling these days. Engineering is about problem solving within the resource constrains and to a specification. Getting the specification right and fitting in the resource constrains are the biggest challenges that only experience will prepare for, because these are domain-specific.
CS and engineering studies can give you a toolkit to solve some problems and helps to give you to develop a "gut instinct" to pick a solution.
- I got a lot better at my job because my toolbox was a lot bigger
- I developed a much 'broader' view of the field, which became unified instead of a collection of subfields
- I realized that there was even more that I didn't know about, and that I should keep reading !
Great, you spent two weeks saving two percent of compute time and now only two people will ever be able to change this code. WTF?
That said, I think the best way to learn these kind of things is on the job, if you find a company kind enough to let you practice the basics.
This advice probably depends heavily upon the school. At mine, a Software Engineering degree required the same classes as Computer Science, but with extra engineering ones on top.
Theology was regarded as a science in the middle ages, but its appeal was to evidence found in scripture and tradition rather than empirical data. I honestly don't know if it's regarded in the same way today.
With that said, scientific methodology can be useful in the exploration of math. I've used computation to guide me towards a proof. For instance if the problem is: "Find all numbers such that ...," and the first 10 of those numbers are powers of two, hmmmm... guess where you'll start looking for a proof. But the computation itself was not a proof.
Computers can be studied from a pure math angle, e.g., computing the order of a sorting algorithm. But they can also be studied by treating a computer as an unknown whose properties are discovered by empirical testing of hypotheses. For instance, benchmarking is such a pursuit.
Given this: in what universe is Computer Science a science? The Scientific Method is used here and there, of course, but it's hardly the core technique.
And I guess theoretical physics is also not science.
Moreover CS does use experimentation to answer questions. That’s basically all of ML for example.
Imagine someone designing and constructing a bridge, and right after it was possible to walk gingerly across one part of it, the people in charge of the project said "hmm, could you put a parking area in the middle?". And then, right after you had done that, came back and said "great, but we'd like to make the whole thing a double decker so we can run a train line across the lower level?". Miraculously, you pull this off, and then they announce that they've realized that the bridge needs to open in the middle to allow large boats through.
We (generally) do not allow engineering projects rooted in the physical world to have fluid specifications, because of the cost and complexity of doing so.
Although there is a real cost and huge complexity to allowing software engineering to accomodate goal flexibility as much as we do, it is vastly less than would be the case for most mechanical and chemical engineering projects.
And the reality is that human goals do change as exposure to a project takes place. There are probably many people involved in bridge specifications who wish they could have gone back and significantly altered some part of the design, based on things learned during construction and early use. But we don't allow that, and so we're left with an impression that only non-software engineers are good at handling performance specifications. It's not true.
Source: I studied EE, did not get a PE or any sort of license beyond my degree, and worked in defense, and commercial engineering jobs
In the realm of software engineering I don't know that we've had a catastrophic failure where the infrastructure costs of repair were in the billions or there was tangible loss of life. The biggest example that comes to mind was the explosion of the Ariane rocket because the software caused the rocket to rotate in the wrong direction so the ground-controllers executed a self-destruct... maybe pieces of a Tesla that crashed while on auto-pilot would be a candidate for physical objects we can hold in our hands to remind us that software bugs can kill?
However, that search took me to an example that I didn't recall, resulting in loss of life. I'll probably reference this story about the Therac-25 in the future as it hits on a number of clear software engineering failures:
-- https://www.bugsnag.com/blog/bug-day-race-condition-therac-2...
You can also chalk it up as a non software engineering failure because the sensor hardware is what failed first.
It's not very clear cut.
The multi-day 2003 blackout in the Northeast US states and Ontario, Canada qualifies in terms of impact (many billions of $). It was a systemic flaw with a software bug as a proximate cause. I think most major failures with high impact in a software-intensive system will sort of look similar: a software fault that cascades to the real world.
https://en.m.wikipedia.org/wiki/Northeast_blackout_of_2003
Other examples might be the various outages in airline reservation systems.
If you’re interested in this kind of thing, the archives of the Usenet newsgroup comp.risks are interesting (not sure if it’s still active).
This same style of development could be applied to any software development venture, but it's usually not, because most software doesn't benefit from it enough to warrant the extra time and expense.
(The majority of my avionics work has actually been directly working on such simulation systems, building and certifying them for formal verification use, but I have done some verification work on avionics boxes as well.)
Outside of my personal experience, I am aware of projects using things like TLA+. I suspect that is more common the higher up you go in system criticality. Even within avionics, not every system requires the same level of scrutiny... for example, you need to more exhaustively test a flight controls system than a flight management system.
In any case, the FAA does not dictate particular tools. They dictate a level of quality that any tools used must adhere to (the tools themselves must be certified based on how they are used), but otherwise a project is welcome to use whatever tools they wish. Or, no tools.
This is Real Scottsman nonsense. Algorithms can be easily tested, and can be modified and optimized to meet a host of requirements, from computational complexity to real-world efficiency to fairness to privacy. We specify the performance requirements of software all the time.
That would be system programming, part of computer engineering actually [1], not software engineering. Also software engineering usually does include some computer engineering.
[1] https://en.wikipedia.org/wiki/Computer_engineering
But when things do not work, and you are required to do retrospectives and post-mortems detailing why things break, and when you are required to mitigate risks from things breaking again... that's when you can no longer get away with simply seeing yourself as a someone abstracted from the low-level stuff. You will now have to understand things, and if you don't, your organization will find someone else that will.
If you say "we fixed the issue" 10 times in a row for the same issue, you lose credibility and the organization will look to replace you.
If a problem in your product is affecting my ability to do business, you either give me a proper explanation or I will find a replacement product.
The prototyping phase of a product is just an engineering honeymoon, it does not last forever.
A pure computer scientist is like the engineer that designs with SolidWorks and has never actually run a Bridgeport, or had to pop the access panels and grease bearings day-to-day.
So I dropped out, went working for a few years, then enrolled at an another university, then went working again abroad. Now I'm preparing myself for my last exam and will write my Bachelor thesis in the first half of next year.
I plan to graduate, even if it's the last thing I do in life.
(Good day for Dijkstra quips on HN today.)
Today cutting edge astronomy isn't that removed from telescope design. Understanding how the instrument works and it's limitations is pretty much essential to understand the data it produces.
A lot of data scientists DO NOT want this. They're heavy on the science and less so on the software engineering.
I think this is one of the reasons Python took off.
Having to learn generics, type safety, exception handling, etc turns out to be a real pain when you're also learning about neural networks, AIs, etc.
Microsoft was clearly going for a best of both worlds approach - .Net if you need it, just your data if you don’t. I find it a pain in the ass, but all the data guys at work love it because they can mix and match with our existing code and still do their own thing.
I've already started seeing organic adoption of assertions.
2019: “static types are amazing!”
I’m still salty about this shift. No one really goes back and admits, “maybe we were all wrong.”
IMO, the best explanation is the high influx of new, young devs results in ideological conformity in lieu of developed aesthetics. This also explains the unnatural amount of sway by so-called “thought leaders.”
When you’re trying to ship an extensive application and building out features that few customers may ever use, types absolutely slow you down. When you’re integrating with a 3rd-party API, you have two differences:
1. relatively high confidence the API won’t change much, which makes implementing typed code lower risk and higher ROI
2. a slower feedback loop over the “reload the page” of rolling your own, so types catching issues earlier than heavy integration tests is much more valuable
I use untyped Ruby/Rails code for all of the CRUD, and golang AWS lambdas for anything integrating with SDKs/APIs. Best of both worlds, in my experience.
There are still some areas where it falls flat, but it is far more usable than before (very pleasant, in fact).
Having tried TypeScript and Kotlin, TypeScript is like a half-assed type system that gives you cryptic error messages in compile time and mindfuck stack traces in run time.
Using assert(value, message?) function ends up being more useful and ergonomic.
Python took off for data because the frameworks and libraries around it. Without IPython/Jupyter, dataframes, Scipy, it would have way less marketshare.
I fully support offering degrees that train you for the practical aspects of software engineering without wasting time on things you’re unlikely to ever use in that field. At the same time, one of these things is not like the other, you can’t call them the same.
Though, I imagine it is difficult for universities. They're trying to be more theoretical and less practical than trade schools, despite the majority of undergrads do not continue to pursue more degrees. I imagine if universities shifted its focus to more applied sciences, it might be even harder to keep the number of applications for masters and phd programs up.
I doubt there will be any impact on MS/Phd applicants. The people who are interested in the fundamentals are usually interested from the start.
those trades schools that popped up are good enough
While, I support trade schools for SE, they don't provide a "complete" education.
Higher education was always for elitists that had the privilege and time to pursue "complete" education. Everyone else just got a job, they went to trade school or had an apprenticeship or just less specialized work. A lot of that kind of work - briefly in history and into the present - required having a degree. Software engineering is not one of those.
So don't get it twisted. People that want to pursue a complete education because they are interested in the subject can keep going to academia. For everyone else, it is a waste of time, software engineering trade schools are cheaper, faster and good enough.
I've encountered so many definitions of Computer Science and Software Engineering that I lost track. Every school seems to interpret the brief slightly differently.
Some school have Computer Science as a spin off of the mathematics department. You can graduate without writing a single line of code. As Knuth said in one of it's memos: "Beware of bugs in the above code; I have only proved it correct, not tried it."[0]
Others have Computer Science as a spinoff of EE (MIT and Berkley are like that) where CS is the skills you need once the circuits are reliable enough you don't have to care too much for their implementation.
Lastly, I've seen "Software Engineering" courses at some places that are almost trade-school-esque discipline (beware of some masters degrees [1]) that's basically what would have been called data processing or IT/Information System.
Other places consider it double major in CS and Engineering where there's dedicated courses on software design. As a rule of thumb, if the OS class is about mutex and semaphore you are at the right spot. If there's group policy involved, look at transferring.
[0] http://staff.science.uva.nl/~peter/knuthnote.pdf [1] https://blog.alinelerner.com/how-different-is-a-b-s-in-compu...
At my institution, the Software Engineering students take the same courses as the Computer Science students. However, the SE program has less flexibility in electives, as nearly all of their electives have been replaced by mandatory engineering courses.
In both cases, it isn't done to trust the theoreticians with power tools: or hold the guys in the shop responsible for the deep magic, either.
Alogrithms, & data structures are one of the obvious fully shared concerns between CS and SE.
Also, as a software practitioner, I can give you multiple examples of reaching into CS research and then directly appying it to code. A favorite ~recent example was discovering "Power of Two Choices" (for bins and balls) a few years ago, and then, that very day, doing a prototype of a cache using that approach. I seriously doubt a Mechanical Engineers would have the same experience with ~contemporary fundamental physics theoretical papers.
I don’t mean that as an insult, at all, just a recognition that as a field, CS is maybe 75 years old.
I wouldn't take it as an insult, if I were a CS worker, however. That just means that the Gausses, Euclids, etc. of this field have yet to appear. All the warts of this field aside, it does offer a chance for making a dent in history. Something the young workers in the field may want to keep in mind ..
Comparing it to fundamental physics is like comparing it to abstract math — in which case the relationship is still the same:
Physicists building the LHC pushed engineering forward.
Math researchers have substantially pushed numerical computing forward.
It's merely that, to pick some famous names: what leslie lamport or simon peyton-jones or donald knuth do with their daily professional lives and output has a passing similarity with what titus winters or linus torvalds or raymond chen or .. have, but not much more than that. And both groups know stuff the the other one does not.
Can we recognize that your bachelor's degree is just a starting point, that leaves you fundamentally unqualified for many tasks, and you'll have learn (via painful experience, apprenticeship [if that is emotionally possible for Gen Y/Z], or self study) many things to become a journeyman software expert?
Do you need to understand the basics of algorithmic complexity? Yes. Do you need to be able to write a compiler? No. (It's useful, but unless it is your major, no, and you can learn it later.) I would trade off compiler design for a software configuration management course. Should you understand some crypto basics? Yes. But I'd rather employ someone who understands TLS and PKI than someone who has written a toy project to implement a cipher.
This is not a generational thing. I know at least as many entitled older folks as I do detached younger folks.
Moreover, part of the drive for saving dying industries is because the folks in those industries don't want to pivot because that's hard.
Some people just want life to be easier and give in to that. It is easy to sympathize with that because life is hard and it would be nice.
"You can't parse HTML like that, it's not regular"
"What do you mean regular? Look the regex works no need to complicate things we're trying to resolve this JIRA ticket"
See, no need for these fancy compilers!
More generally, I can always come up with something you can't understand without some specialised knowledge. I could argue that you couldn't possibly be a computer scientist / software engineer unless you understand the foundations of digital logic -- how else to understand safe implementation of crypto, caching and VM? Who cares about big O when people write pointer hungry code that faults to main memory every cycle?
I guess we might both be arguing for 'knowing what we don't know' and where to start looking.
ok boomer
Nice flamebait.
We need to rethink academia and I personally think reducing the length and objectivity is a better answer.