michael0x2a

Personally, I'm a fan. I felt there was way too much LLM-related content prior to the ban. It was drowning out other topics and making the sub too one-note.

I guess if I had to draw a line, I would personally be ok with posts that are related to creating LLMs. For example, I'd be ok with posts about new mathematical techniques in machine learning, since those topics are usually fairly rigorous and so more likely to teach me something new about math or CS.

However, I'd be ok with banning posts about using LLMs or discussing/speculating about the implications of LLMs on the broader tech industry. I often find the former to usually be uninteresting from a technological POV: such posts often just boil down to covering yet another way of gluing together/configuring LLMs. The latter is incredibly repetitive. I'm not interested in some random person X rehashing the same old "are LLMs good/bad/revolutionary/overhyped" talking points.

So, I'd be ok continuing to ban the remaining bullet points on your example list.

To boil it down even more: I think LLMs as a technological construct can be interesting, so would be ok with posts that crack open the abstraction layer. But higher-level posts that treat them as black boxes/building blocks tend to be kind of boring/simplistic, at least as of now.

If this sort of distinction is too nuanced to cleanly enforce, I think it could also be reasonable to either:

1. Continue the current blanket ban on LLM-related posts, or

2. Allow them for only 1 day of the week. It would create a release valve for LLM enthusiasts while still preventing overrun. It could also maybe help improve the signal-to-noise ratio for LLM-related posts. Forcing them to compete over a short timeslot will hopefully mean there's less votes flowing to low-effort/low-novelty posts.

To be completely honest, I would just work through a standard intro-to-programming book or course.

Having background knowledge in linux is directly useful for only a few subdomains of computer science -- systems programming, operating systems, perhaps distributed systems, etc... However:

1. These domains are relatively advanced ones which won't make sense for you to study now.

2. Having background knowledge in linux won't really give you a head-start in mastering the fundamentals of problem solving and computer science. Usually, these intro courses are structured so that you are working against an abstract and simplified model of a computer; knowing the underlying implementation details will not be helpful at this early stage.

Instead, I would perhaps try picking a course that aligns with the underlying reason why you became interested in Linux in the first place. This in turn would make it easier for you to remain motivated as you study programming.

For example, if you were first interested in Linux because you wanted full control over your machine + to use it to the fullest possible capability, I would perhaps consider starting with C. Alternatively, if you were drawn to linux because you wanted to script and automate tedious tasks and wanted an OS that made doing so easier, then I would maybe look into something like Python.

If you aren't sure, just pick any course that looks well-taught and comes with solid exercises/homework. How exactly you first started learning programming is not super important in the grand scheme of things; once you have a solid understanding of one programming language, it will become substantially easier to learn new ones.

IMO you should try and maintain a GPA of roughly ~3.5 (assuming 4.0 is the max). It's a respectable grade and is usually enough to let you clear most baseline gpa filters.

You'll likely start to see diminishing returns if you chase for something much higher. Instead, I think your time is better spent either:

• Working on projects or joining tech-related extracurriculars (robotics clubs, CTFs, whatever) if you want to go into industry. Ultimately, your goal is to develop a unique/interesting resume and portfolio, which will make you stand out to recruiters. This in turn makes it easier to land internships/jobs.

• Doing undergrad research, if you want to go into academia. In this case, your goals are to get actual research experience and build personal relationships with some of your professors so they can write you a strong recommendation letter. These are the two factors that matter most when applying to a PhD program, after you pass the initial GPA filter.

• If you want a very specific/prestigious/niche job after university, prioritizing electives and projects related to that job and deprioritizing unrelated ones. (You will want to get high grades for these specific classes + prioritize fully mastering the material.) You'll likely have much less time to study after you graduate. So if you have a specific dream job in mind, it'd be optimal to try building the skills you need for it now.

IMO targeting a gpa of 3.0 could work if you spend your increased free time really productively, but is a bit risky. You're one bad quarter away from dipping to a 2.x gpa, which would not be a good look.

Caveat: I live in the US west coast; norms may be different in your region. You should try connecting with people in the industry (via career fairs? meetups?) or chat with your advisors and upperclassmen to confirm the above.

Writing code is similar to writing an essay or an article. Your first draft is usually kind of shit, and you need to go through several rounds of editing and revising in order to arrive at something that's polished and presentable.

You should approach writing the code with a similar mentality. It's unreasonable to expect your first attempt to be perfect; make sure to always reserve some time to review and edit your work.

Concretely, once you have a working solution, go back and see if you can edit it to be more clear, readable, and concise. Are there chunks of logics you can express in a more concise way using Python language features you may not have remembered at the time? Do you spot any chunks of code that seem unnecessarily complex or inefficient, and could be replaced by a different implementation? Are there any chunks of code that would be safe to just outright delete? etc.

Really challenge yourself to critique every aspect of your code and think through what, if anything, you can improve/remove.

Once you're done, compare your edited work to the solution. If the solution is still cleaner then yours, analyze it and try writing down what specific techniques the solution used compared to your work. Did they have a better idea then you? Did they have the same idea, but expressed it more concisely? etc.

Doing all of the above will obviously require you to spend more time on each exercise. But I think it'll do a lot to help you train your ability to write clean and elegant code.

Some of the other commenters have suggested dividing work based on features instead of layers, which I agree with.

Some other things I recommend doing:

1. Have a formal planning/brainstorming session at the start, where your teammates agree on what specific features need to be built and the broad high-level architecture of your code. (Which core libraries/frameworks will you use? Which components will you need to build? How will they interact with each other? What data will your database store? etc). You don't need to lock down every detail now, but you should make sure everybody's on roughly the same page of what needs to be built, and the overall direction.

2. If your project is big (will take multiple weeks to complete), try and break down the list of features/tasks into items that feels like it'll take roughly a day or so to complete (or shorter). Having smaller bite-sized tasks can make a large project feel more manageable.

3. Start by creating a "walking skeleton" -- a super minimal sketch of your overall architecture. For example, maybe create a database with just a single table, a backend with just two routes that'll read/write to the table, and a frontend that'll interact with that route. If you need to deploy this app as a website (instead of just running it locally), do that too.

   The goal of this is to confirm you are able to successfully use the libraries you picked to get a super bare-bones app working and running end-to-end. This helps you both confirm that (a) your overall tech choices will work reasonably well together and (b) gives you just enough structure to let you split up and start working on features independently without constantly stomping over each other.

4. Consider doing code reviews: before you can merge in code into the main branch, have somebody else in the group review your change first. This will (a) ensure the code author will have a second pair of eyes on every change to double-check for bugs and mistakes and (b) gives the reviewer an opportunity to ask questions and learn about what the code author is working on.

   Normally in industry, every single change must be code reviewed. Since this is a student project, you can maybe relax a little and skip code reviews for smaller tweaks and bugfixes. But I do think it'd be a good idea to wait + ask for code review on bigger ones.

Whats the best thing to do when none of us are that great in programming ?

The same thing you'd do if you were good at programming, just more slowly.