Computer science is not software engineering
swizec.com
swizec.com
That’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.
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.
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.
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.
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.
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.
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.
We need to rethink academia and I personally think reducing the length and objectivity is a better answer.
(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.
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.