this post was submitted on 24 Jul 2025
226 points (96.3% liked)
Showerthoughts
36191 readers
1647 users here now
A "Showerthought" is a simple term used to describe the thoughts that pop into your head while you're doing everyday things like taking a shower, driving, or just daydreaming. The most popular seem to be lighthearted clever little truths, hidden in daily life.
Here are some examples to inspire your own showerthoughts:
- Both “200” and “160” are 2 minutes in microwave math
- When you’re a kid, you don’t realize you’re also watching your mom and dad grow up.
- More dreams have been destroyed by alarm clocks than anything else
Rules
- All posts must be showerthoughts
- The entire showerthought must be in the title
- No politics
- If your topic is in a grey area, please phrase it to emphasize the fascinating aspects, not the dramatic aspects. You can do this by avoiding overly politicized terms such as "capitalism" and "communism". If you must make comparisons, you can say something is different without saying something is better/worse.
- A good place for politics is c/politicaldiscussion
- Posts must be original/unique
- Adhere to Lemmy's Code of Conduct and the TOS
If you made it this far, showerthoughts is accepting new mods. This community is generally tame so its not a lot of work, but having a few more mods would help reports get addressed a little sooner.
Whats it like to be a mod? Reports just show up as messages in your Lemmy inbox, and if a different mod has already addressed the report, the message goes away and you never worry about it.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
Yes, it's code. We studied and iterated on that code long before the first computer, we came up with architectures that influenced the creation of the hardware to run it
The way they teach it has probably changed since I went through, but we had software engineering as a concentration. I actually picked networking and just took the all the software engineering courses because it had less math requirement lol
But it was mostly theoretical, with hands on homework to demonstrate it in practice. Everyone had certain courses they had to take, like at least 3 semesters of programming, discrete math, data structures, and a few others along with gen eds.
You just had to get a certain amounts of credits from different levels, so you could go through and pick what you wanted to focus on. You could dive into more theoretical or practical, high level or low level, but everyone had to study the full stack enough to understand it at a basic level
But it's all castles made of sand. Even before the first computer, we've been iterating on these ideas... Studying them and building higher
The line between the science and engineering is blurry...Hell, our jobs are blurry and usually cross-discipline