folks who don't use any version control scare me...

TL;DR :

"when i die i want my group project members to lower me into my grave so they can let me down one last time"

STORY TIME

Last year in College, I had two simultaneous projects. Both were semester long projects. One was for a database class an another was for a software engineering class.

As you can guess, the focus of the projects was very different. Databases we made some desktop networked chat application with a user login system and what not in Java. SE we made an app store with an approval system and admin panels and ratings and reviews and all that jazz in Meteor.js.

The DB project we had 4 total people and one of them was someone we'll call Frank. Frank was also in my SE project group. Frank disappeared for several weeks. Not in class, didn't contact us, and at one point the professors didn't know much either. As soon as we noticed it would be an issue, we talked to the professors. Just keeping them in the loop will save you a lot of trouble down the road. I'm assuming there was some medical or family emergency because the professors were very understanding with him once he started coming back to class and they had a chance to talk.

Lesson 1: If you have that guy that doesn't show up or communicate, don't be a jerk to them and communicate with your professor. Also, don't stop trying to contact the rogue partner. Maybe they'll come around sometime.

It sucked to lose 25% of our team for a project, but Frank appreciated that we didn't totally ignore him and throw him under the bus to the point that the last day of class he came up to me and said, "hey, open your book bag and bring it next to mine." He then threw a LARGE bottle of booze in there as a thank you.

Lesson 2: Treat humans as humans. Things go wrong and understanding that will get you a lot farther with people than trying to make them feel terrible about something that may have been out of their control.

Our DB project went really well. We got an A, we demoed, it worked, it was cool. The biggest problem is I was the only person that had taken a networking class so I ended up doing a large portion of the work. I wish I had taken other people's skills into account when we were deciding on a project. Especially because the only requirement was that it needed to have a minimum of 5 tables and we had to use some SQL language (aka, we couldn't use no-SQL).

The SE project had Frank and a music major who wanted to minor in CS (and then 3 other regular CS students aside from me). This assignment was make an app store using any technology you want. But, you had to use agile sprints. So we had weekly meetings with the "customer" (the TA), who would change requirements on us to keep us on our toes and tell us what they wanted done as a priority for the next meeting. Seriously, just like real life. It was so much fun trying to stay ahead of that.

So we met up and tried to decided what to use. One kid said Java because we all had it for school. The big issue is trying to make a Java web app is a pain in the ass. Seriously, there are so many better things to use. Other teams decided to use Django because they all wanted to learn Python. I suggested why not use something with a nice package system to minimize duplicating work that had already been done and tested by someone. Kid 1 didn't like that because he said in the real world you have to make your own software and not use packages. Little did he know that I had worked in SE for a few years already and knew damn well that every good project has code from somewhere else that has already solved a problem you're facing. We went with Java the first week. It failed miserably. Nobody could get the server set up on their computers. Using VCS with it required you to keep the repo outside of the where you wrote code and copy and paste changes in there. It was just a huge flop so everyone else voted to change.

Lesson 3: Be flexible. Be open to learning new things. Don't be afraid to try something new. It'll make you a better developer in the long run.

So we ended up using Meteor. Why? We all figured we could pick up javascript super easy.Two of us already knew it. And the real time thing would make for some cool effects when an app got a approved or a comment was made. We got to work and the one kid was still pissed. I just checked the repo and the only thing he committed was fixing the spelling of on word in the readme.

We sat down one day and worked for 4 straight hours. We finished the whole project in that time. While other teams were figuring out how to layout their homepage, we had a working user system and admin page and everything. Our TA was trying to throw us for loops by asking for crazy things and we still came through. We had tests that ran along side the application as you used it. It was friggin cool.

Lesson 4: If possible, pick the right tool for the job. Not the tool you know. Everything in CS has a purpose. If you use it for its purpose, you will save days off of a project.

Why do people jump from c to python quickly. And all are about machine learning. Free days back my cousin asked me for books to learn python.
Trust me you have to learn c before python. People struggle going from python to c. But no ml, scripting,

And most importantly software engineering wtf?
Software engineering is how to run projects and it is compulsory to learn python and no mention of got it any other vcs, wtf?

What the hell is that type of college. Trust me I am no way saying python is weak, but for learning purpose the depth of language and concepts like pass by reference, memory leaks, pointers.

And learning algorithms, data structures, is more important than machine learning, trust me if you cannot model the data, get proper training data, testing data then you will get screewed up outputs. And then again every one who hype these kinds of stuff also think that ml with 100% accuracy is greater than 90% and overfit the data, test the model on training data. And mostly the will learn in college will be by hearting few formulas, that's it.

Learn a language (concepts in language) like then you will most languages are easy.

Cool cs programmer are born today😖

First company:

- being sat at an office that didn't have chairs with proper back support. It would kill my back every day. Like sitting on a bar stool coding.
- not having access to basic resources (cafeteria, salary bonuses)
- being seriously underpaid ($200 under)
- not having an IT process pipeline (yeah, this is a huge one): no JIRA, no git, no VCS, no continuous integration, etc. I fucking spend 45% of the time fixing coding-unrelated shit.

Second company (very aggravating):

- dumb frontend bitch and privileged colleague who both kept telling me months on end to shut up and who wouldn't listen to my advice on anything, while my advice would actually help the company advance in productive ways. The key here is being told to shut up while stagnating. i.e. dead end job.
- people advancing in the company based on nepotism and favoritism, based on having tits and ass, rather than skills and independence.

- pointlessssssssss meetings where decisions are made solely based on the opinion of Mr. favorite senior dev. The rest just sits there like a bunch of sad saps and yay-nodders. Incompetent PO's who "would like to hear your input" but then when you give it, they completely dismiss you.

- pointlessssssssss monthly meetings with stakeholders, where the dev teams do nothing but clash and act like pussies in front of the PM just to get in his favor, but behind scenes continue to make the same mistakes and telling the CEO everything is fine. Goodness, how can it get more unproductive.

- completely antisocial and nepotistic 'colleagues' who won't even talk to you, let alone smile at you or be friendly. You saying good morning and them pretending you're vapor that doesn't exist. Go go company atmosphere! Especially during lunch, those are the worst times. Imagine sitting at lunch where everyone looks like you killed their dog and the rest is huddled up in little high school groups.
What else? The incessant and pointless smalltalk that makes me want to bang my head against the wall. Talking about dogs, kids, what show was on tv last night. The fuck man, do you have a brain?!

Third company:

- HR bitches who think they are the shit and developers are antisocial, helpless misfits, but they work with computers and they don't even fucking know what a status bar is! The irony!

- forced socializing and stigmatization for the opposite. Imagine coming into a company and you don't say good morning. Should that be a problem? No. Instead, everyone starts dogging on you and hating you just because you didn't smile in their faces and said: hiiiiiiiiiiii how did you sleep? Did you feed your dog? Fuck you.
Elliot (Mr. Robot): "Wouldn't it be awesome if there was a mute button for life?" -boop, boop, boop, boop...- Ahh.. there.. that's much better."

- CEO's sucking up to you but when it comes to salary increase, they say shit like: "Ahhh ya know, it's kinda difficult." Yet another dead end job.

I've been working like a mad woman in a startup for 3+ years now. They feel like 10. Or at least the tech stacks we went through.
Never, ever join a startup, regardless of compensation, unless you know you can emotionally and mentally recover from that startup failing as if it is yours, not your bosses. Otherwise, it's just a shitty short experience.

My long experience is shitty, but man. I don't know.Those who built google, wanted to make a search engine. Did they know they're gonna be good? NO. This is the result of them being good. They now have that great product that succeeds and is able to become a self-referential piggy bank. You cannot be a self-referential piggy bank based on a fucking belief and idea, and a bunch of VCs who already put money in you. You know why? BECAUSE GUESS WHO IS THE ONE RESPONSIBLE FOR SUSTAINING YOUR START UP NOW?

The bloods and passions of youth, that join your startup, thinking they can make a difference, and you just undermine them constantly thinking that no engineer can make a difference if they can't ensure compliance with your dumb funding strategy.

Don't even get me started on the fact that most people who work for startups, rely on either laziness or passion. It's like a bunch of kids in art school, whose professor doesn't like anything they make, but they still kinda like it hoping one day they leave and become artists themselves. Then they discover that this shit professor actually taught them nothing about creativity in the real world, and what it takes to push something out.

And, it finally fucking hit me.

The reason startups will never work in this year, and beyond, AND TILL I SEE A CHANGE IN ATTITUDE IN 10 YEARS.....

The market won't fucking allow it with the current strategy tech companies are a fan of: hire a bunch of passionate devs who wanna learn a tool through doing our unique work. Doesn't matter. DIVERSITY. THE UNION IS THE PASSION. That's dumb as fuck.
Why?
Here:

- Passionate people do not have to use passion as an incentive, the passion was there, and them getting their idea made or money is the incentive
- If you hire a passionate person - even if they are the fucking best - you just made their passion a tool, in getting your PRs done and shit epics scoped AT BEST, and so the tools you're teaching them to use are getting away with doing less impactful, productive, creative work.

I AM SO DEPRESSED.

markdown is not good enough! the tools aren't there for non-devs and there's no concordance on moving forward *compatibly* for anything other than headers and __possibly__ lists.

md has been around for years and still no consensus on comments, meta data, css, data imports, etc.

i could never in good faith recommend to a non-dev to use markdown, even though every academic and professional writer from legal to journalism should exclusively be using markdown to write and store their documents. the data portability and ease of search, retrieval, collection, distribution, etc of markdown compared to pdf or docx is enormous. markdown is the hex format of text, the perfect layer of data and visual so that the user and the computer can both operate on text as blocks of data rather than weirdly styled paragraphs that need to be reformatted BY HAND for citation-style or journal format, or paper size. FOR EACH SUBMISSION. Academics literally rewrite their 100-page papers to accommodate up to 10 different submission requirements.

They could be clicking MLA vs Chicago and/or using a journal's stylesheet to recompile for its styles.

Today there is some support from zotero et al to take away some of the pain, but it makes ZERO SENSE for writers to have to keep and store and keep up to date, multiple versions of the same document. Git pull does not exist for them. But the worst part is that git isnt the solution to their problem. They need a compiler more than they need version control. But they also desperately need vcs. They ALL literally have a million files named "dumdum.dumFINAL-3084_lastversion \2020, this one.dum".

They dont have git or anything like it, because they need a line-by-line solution like markdown for git to become effective.

All of writing is basically mired in the fact that people cant even roll up their paragraphs and see what the fuck it is theyre saying. Most writing reads like a long scroll through some nonsense that goes nowhere. Like this rant. but the point is that markdown and line-by line editing actually produces more logically sound writing. You start to think in terms of defining ideas in blocks, ... like code.

Good code is a lie imho.

When you see a project as code, there are 3 variables in most cases:

- time
- people / human resources
- rules

Every variable plays a certain role in how the code (project) evolves.

Time - two different forms: when certain parts of code are either changed in a high frequency or a very low frequency, it's a bad omen.

Too high - somehow this area seems to be relentless. Be it features, regressions or bugs - it takes usually in larger code bases 3 - 4 weeks till all code pathes were triggered.

Too low - it can be a good sign. But it should be on the radar imho. Code that never changes should be reviewed at an - depending on size of codebase - max. yearly audit. Git / VCS is very helpful here.
Why? Mostly because the chances are very high that the code was once written for a completely different requirement set. Hence the audit - check if this code still is doing the right job or if you have a ticking time bomb that needs to be defused.

People
If a project has only person working on it, it most certainly isn't verified by another person. Meaning that only one person worked on it - I'd say it's pretty bad to bad, as no discussion / review / verification was done. The author did the best he / she could do, but maybe another person would have had an better idea?

Too many people working on one thing is only bad when there are no rules ;)

Rules. There are two different kind of rules.

Styling / Organisation / Dokumentation - everything that has not much to do with coding itself. These should be enforced at a certain point, otherwise the code will become a hot glued mess noone wants to work on.

Coding itself. This is a very critical thing.

Do: Forbid things that are known to be problematic in the programming language itself. Eg. usage of variables in variables, reflection, deprecated features.

Do: Define a feature set for each language. Feature set not meaning every feature you want to use! Rather a fixed minimum version every developer must use and - in case of library / module / plugin support - which additional extras are supported.

Every extra costs. Most developers don't want to realize this... And a code base that evolves over time should have minimal dependencies. Every new version of an extra can have bugs, breakages, incompabilties and so on.

Don't: don't specify a way of coding. Most coding guidelines are horrific copy pastures from some books some smart people wrote who have no fucking clue what you're doing and why.

If you don't know how to operate on people, standing in an OR and doing what a book told you to do would end in dead person pretty sure. Same for code.

Learn from mistakes and experience, respect knowledge from other persons, but always reflect on wether this makes sense at this specific area of code.

There are very few things which are applicable to a large codebase on a global level. Even DRY / SOLID and what ever you can come up with can be at a certain point completely wrong.

Good code is a lie - because it can only exist at a certain point of time.

A codebase should be a living thing - when certain parts rot, other parts will be affected too.

The reason for the length of the comment was to give some hints on what my principles are that code stays in an "okayish" state, but good is a very rare state

First and foremost, students should be carefully taught the logic and mentality behind programming. Most of the time I see that the introductory programming courses waste so much energy in teaching the language itself. So students kinda just get fucked cause many people end up ending the course without having actually gained the "programming perspective".
Stop teaching pointers and lambdas and even leave the object oriented stiff till later. If a student doesn't know why we use a For loop then how can they learn anything else.
I believe once that thing in your brain clicks about programming, everything goes smooth from there... kinda :P

Second of all, and this pertains mainly to the engineering and science disciplines.
We need a fundamental and strong mathematical foundation. And no I don't mean taking fucking double integrals. Teach us Linear Algebra, Graph theory, the properties of matrices, and Probability theory.
One of the things I suffered from most and regret in university is having a weak foundation in math and having to spend more time catching myself up to speed.
It's so annoying reading a paper on a new algorithm or method and feeling like an idiot because I can't understand what magic these people did.

Numerical Methods...
Ok this is more deeper, maybe a 2nd year course.
But this is something we take for granted.
Computers don't magically add and subtract and multiply.
They fuck up.
And it'll bite you in the ass if you're not even aware that the computer we all love so much isn't as perfect as we think

Some hardware knowledge.
Probably a basic embedded systems course with arduinos
just so you can get a feel for how our beautiful software actually makes those electrons go weeeeeeeee

And finally
Practice practice
Projects projects
like honestly
just give me the internet and some projects
Ill learn everything else
Projects are the best motivation
I hate this purely theoretical approach
where we memorize or read code and write these stupid exams
Test what we are capable off
make us do projects that take sleepless nights and litres of coffee
And judge our methods, documentation, team work, and output

Team work skills and tools (VCS, communicating, project management, etc.)

Documentation and Reporting
Properly
:)
maybe even with LaTeX :D

Yeah that's the gist of whats on my mind at the moment regarding an ideal computer science education
At least the foundations
The rest I leave it to the next dude.