I have a BEng in software engineering. It wasn’t thst different from a normal BSc in CS. Bits that stood out to me was industrial stuff around building and programming our own circuits, making our own (very simple) compiler, and some assembly modules, I had more maths stuff but that was for 3D graphics. My dissertation was a temperature control system for radiators.
I don’t really use any of it in my job, although I did do a ton more programming modules than most CS of the time, and those programming modules prove very useful.
Computer science is basically the study of software engineering, because computer engineering means hardware, which has grown into a separate discipline that computer science only touches on
Programming is writing code for the ticket, architecture is designing the system that gets written into tickets, and software development is the whole process
But all these disciplines grew faster than language, so really the titles are whatever you want them to be
Computer science is basically the study of software engineering
That’s not at all true if you ask me. Computer science is the study of data and computation, on a theoretical level. Software engineering is not theoretical at all, but very practical.
Here’s the thing…all of computer science is based on the practical, and software engineering is based on the theoretical
The data and computation being studied? We made it up. We don’t need to do it any particular way, we’re playing with ideas to interface to computers. Computers we made up too
Software engineering is using the lessons we learned by studying how others did things and how it works out in practice
We teach students computer science to make them into software engineers. You can still study how things are done as a separate career, but the two ideas are like an ouroboros. It’s a cycle of creation and analysis
I don’t understand this at all. Computer science is based on theoretical foundations that were developed way before any actual computer existed. This goes back more than 100 years.
We teach students computer science to make them into software engineers.
That’s only true if you studied a very practically-oriented education. Such educations are usually called “Software engineering” rather than “Computer Science”.
As a computer science graduate myself, my university definitely did not try to make me into a software engineer. It was very theoretical, with a clear focus on further research if that was what you wanted to pursue. You could get through the education quite okay and only ever write very little actual code. It was the maths that was the harder part to write.
I studied computer science as well and I share this sentiment.
Although I’m happy about my degree because I’ve learned many things I would otherwise miss, I also wish my degree prepared me more for the industry. There’s a disconnect between academia and the industry.
What I’m mostly concerned with is how to build software that can grow with 10ish team members. I find it hard to find good academic sources on this matter.
It’s methodology. Basically what you need is the correct amount of process - you can pick agile or scrum or whatever, and then you follow it to the amount that it makes sense. If you over-adhere to it, it slows things down to a crawl
Once you get up to 10 team members, you need to do things like feature branches, code reviews, and rigid style. You should also add in tests… At 10 you don’t have to have full coverage, but you need to be able to exercise your system enough to know when something breaks immediately
You also need ownership. You need one primary person who is the heart and soul of the code base, and they’re going to be the one who knows the whole thing and gives everyone direction. You can spin off another team at solid interface points, like an API or a plug in system, but you need one person who owns the core system and holds the code debt back
You also can add in code pipelines, enforce docstrings to generate documentation, you need diagrams so people understand how things flow through the system, etc
Ultimately, a lot of it comes down to mentorship. You have to be very hands on teaching people how the code works, and really hold their hand until they gain proficiency over an area. Then let them be secondary owners over that part of the symptom… And you have to make sure to stick them in a place where they’ll be a benefit - as you grow in numbers, it gets easier for each new person to be a drain on progress.
I’m not sure about academic sources…I dropped a lot of keywords in there that might help search, but ultimately it’s about team culture. You can’t just shove it all in at once, you have to slowly add new processes and make sure everyone is moving in the same direction
I know these concepts - after working in the industry for a while. Computer science education barely touched these topics. One professor was passionate enough to hint at test driven development, but that’s about it.
I had a nice teacher who gave us IRL clients over the course of a full year, and basically guided us through the process while teaching us methodology theoretically as we went through the process
I don’t think there’s a better way, honestly the theory is important, but methodology is learned by doing. I really benefitted by learning from my brother… He taught me best practices as he went through school and the workforce. So I pay it forward
I think courses should focus more on teaching how to use libraries and debug tools… Past that, you get into skills that can’t be taught, only learned
I got an education in software engineering, not computer science, and my experience is in line yours. I had a few courses about fundamental computer science concepts but most of my education was in learning a little about many different areas of software engineering, specializing in a few. Most of the education involved working as part of a software team, using tools of the trade, applying common design patterns and that sort of stuff, even when courses weren’t explicitly about that.
I would never call myself a computer scientist, I don’t have the education for it, I however immediately had a software engineering job ready after graduating and felt prepared for it from day one.
I love what computer scientists do within the theoretical domain because it eventually seeps into mainstream languages and tools, in a way I benefit from. I’m just not involved with it myself, beyond when it reaches practical application.
Computer science has always been separate from software engineering.
In my mind:
Both are important in their own right.
I wish I could’ve gotten a software engineering degree
I have a BEng in software engineering. It wasn’t thst different from a normal BSc in CS. Bits that stood out to me was industrial stuff around building and programming our own circuits, making our own (very simple) compiler, and some assembly modules, I had more maths stuff but that was for 3D graphics. My dissertation was a temperature control system for radiators.
I don’t really use any of it in my job, although I did do a ton more programming modules than most CS of the time, and those programming modules prove very useful.
Computer science is basically the study of software engineering, because computer engineering means hardware, which has grown into a separate discipline that computer science only touches on
Programming is writing code for the ticket, architecture is designing the system that gets written into tickets, and software development is the whole process
But all these disciplines grew faster than language, so really the titles are whatever you want them to be
That’s not at all true if you ask me. Computer science is the study of data and computation, on a theoretical level. Software engineering is not theoretical at all, but very practical.
Here’s the thing…all of computer science is based on the practical, and software engineering is based on the theoretical
The data and computation being studied? We made it up. We don’t need to do it any particular way, we’re playing with ideas to interface to computers. Computers we made up too
Software engineering is using the lessons we learned by studying how others did things and how it works out in practice
We teach students computer science to make them into software engineers. You can still study how things are done as a separate career, but the two ideas are like an ouroboros. It’s a cycle of creation and analysis
I don’t understand this at all. Computer science is based on theoretical foundations that were developed way before any actual computer existed. This goes back more than 100 years.
That’s only true if you studied a very practically-oriented education. Such educations are usually called “Software engineering” rather than “Computer Science”.
As a computer science graduate myself, my university definitely did not try to make me into a software engineer. It was very theoretical, with a clear focus on further research if that was what you wanted to pursue. You could get through the education quite okay and only ever write very little actual code. It was the maths that was the harder part to write.
I studied computer science as well and I share this sentiment.
Although I’m happy about my degree because I’ve learned many things I would otherwise miss, I also wish my degree prepared me more for the industry. There’s a disconnect between academia and the industry.
What I’m mostly concerned with is how to build software that can grow with 10ish team members. I find it hard to find good academic sources on this matter.
It’s methodology. Basically what you need is the correct amount of process - you can pick agile or scrum or whatever, and then you follow it to the amount that it makes sense. If you over-adhere to it, it slows things down to a crawl
Once you get up to 10 team members, you need to do things like feature branches, code reviews, and rigid style. You should also add in tests… At 10 you don’t have to have full coverage, but you need to be able to exercise your system enough to know when something breaks immediately
You also need ownership. You need one primary person who is the heart and soul of the code base, and they’re going to be the one who knows the whole thing and gives everyone direction. You can spin off another team at solid interface points, like an API or a plug in system, but you need one person who owns the core system and holds the code debt back
You also can add in code pipelines, enforce docstrings to generate documentation, you need diagrams so people understand how things flow through the system, etc
Ultimately, a lot of it comes down to mentorship. You have to be very hands on teaching people how the code works, and really hold their hand until they gain proficiency over an area. Then let them be secondary owners over that part of the symptom… And you have to make sure to stick them in a place where they’ll be a benefit - as you grow in numbers, it gets easier for each new person to be a drain on progress.
I’m not sure about academic sources…I dropped a lot of keywords in there that might help search, but ultimately it’s about team culture. You can’t just shove it all in at once, you have to slowly add new processes and make sure everyone is moving in the same direction
I know these concepts - after working in the industry for a while. Computer science education barely touched these topics. One professor was passionate enough to hint at test driven development, but that’s about it.
I had a nice teacher who gave us IRL clients over the course of a full year, and basically guided us through the process while teaching us methodology theoretically as we went through the process
I don’t think there’s a better way, honestly the theory is important, but methodology is learned by doing. I really benefitted by learning from my brother… He taught me best practices as he went through school and the workforce. So I pay it forward
I think courses should focus more on teaching how to use libraries and debug tools… Past that, you get into skills that can’t be taught, only learned
I got an education in software engineering, not computer science, and my experience is in line yours. I had a few courses about fundamental computer science concepts but most of my education was in learning a little about many different areas of software engineering, specializing in a few. Most of the education involved working as part of a software team, using tools of the trade, applying common design patterns and that sort of stuff, even when courses weren’t explicitly about that.
I would never call myself a computer scientist, I don’t have the education for it, I however immediately had a software engineering job ready after graduating and felt prepared for it from day one.
I love what computer scientists do within the theoretical domain because it eventually seeps into mainstream languages and tools, in a way I benefit from. I’m just not involved with it myself, beyond when it reaches practical application.