AAU Software Engineering community

Disclaimer: The LinkedIn profile shown in this image is a demo created for illustration purposes only and does not represent a real individual ! @CTBEsoftwareengineers

🏫 Campus Review: CTBE – 5 Kilo Campus CTBE stands for the College of Technology and Built Environment. It's home to Engineering, Architecture, and other related fields like Construction Management. It's split across two campuses: 5 Kilo and Lideta. (The two used to be separate colleges but are now merged under one shared Dean, even though the campuses are geographically apart.) Today, we're covering 5 Kilo campus. 📍 5 Kilo Campus has 6 undergraduate schools (here "school" means an undergraduate department within the college) Ranked from most to least competitive to get into: 1. Software Engineering 2. Electrical Engineering 3. Biomedical Engineering 4. Mechanical Engineering 5. Chemical Engineering 6. Civil Engineering How you get placed at 5 Kilo: - Your entrance exam score + first semester grade are averaged. Meet the cutoff point, and you're placed at CTBE right after first semester. But you won't choose a specific department yet. You'll take common courses (pre-engineering) first. - To get into a specific department, it's your first + second semester average combined. Example: 3.5 in first semester and 3.8 in second semester averages to 3.65/4 that's about 91.25%. Last year, that was enough for Mechanical Engineering (4th most competitive department). - Software Engineering is the most competitive , especially for non-sponsor students. 👉 Full department allocation breakdown coming in a future post. Stay tuned. 🔎 Other notes on 5 Kilo: - Size: Relatively small perimeter-wise. nowhere near as big as 6 Kilo. - Dorms: Located outside of the campus, across the street (unlike other campuses, where learning facilities and dorms share the same compound). Still, the dorms are more spacious and better kept than 6 Kilo's. Also there's a chance your Dormitory might be at 6 kilo. So you learn at 5 kilo but your dormitory is at 6 kilo. - Library: Located at 5 Kilo, open all night. - Food: Lounges available at both the campus and dorm buildings. Government caf

✨The bug that isn't a bug: silent LLM failures✨ If you're building anything with LLM agents or API calls, here's a trap almost everyone falls into: a 200 OK response doesn't mean success.* Most people wrap API calls in try/except and call it "error handling." But LLMs (and a lot of third-party APIs) fail silently they return valid JSON, valid status codes, and just wrong or empty content. Your code sails right past it thinking everything's fine. So a quick fix that saves hours of debugging: 🔹Don't just check response.status_code == 200 validate the content too (right schema? non-empty? within expected bounds?) 🔹Log the raw response on ambiguous failures, not just the exception 🔹For LLM calls specifically: add a sanity check step (e.g., "did this actually answer the question asked?") before trusting the output downstream The pattern: "it ran without crashing" ≠ "it worked." hope this helps ☺️ @CTBEsoftwareengineers

⚡️ Global Dev Tool Trends: September 2026 Edition ⚡️ The software engineering landscape has officially shifted from "AI as a chat assistant" to "AI as an autonomous co-developer." If you are relying purely on standard autocomplete for your projects this semester, here is how the global dev tool ecosystem is evolving right now. The AI-Native IDE Wars (Cursor & Windsurf): Standard editors are rapidly being replaced by AI-native environments. Cursor remains the dominant choice for seamless codebase integration and multi-file edits, while Windsurf is gaining traction as a highly optimized, affordable alternative. Both keep you in the driver's seat while dramatically speeding up boilerplate generation and interactive coding. Asynchronous Background Agents (Jules & Devin): The industry is moving toward agents that work while you attend lectures. Jules operates with its own allocated capacity to autonomously analyze up to 30,000 lines of code, write unit tests, and open GitHub PRs asynchronously without requiring an active prompt session. Similarly, Devin-class cloud tools handle complete multi-step engineering tasks by running parallel agents to close out tickets end-to-end. Terminal-First Orchestration (Claude Code): For developers who live in the CLI, tools like Claude Code are leading the pack for deep repository context and complex terminal-heavy refactoring. It allows you to run multi-file edits directly from the command line. Multi-Agent Platforms (Google Antigravity): The new frontier is engineering your own AI workflows. Platforms like Google Antigravity provide developers with direct environment access to build, test, and deploy autonomous multi-agent systems. It is quickly becoming a standard for building scalable infrastructure with deterministic tool pipelines and formal verification steps. Zero-to-MVP App Builders: For hackathons and rapid prototyping, browser-based builders like Bolt.new, v0, and Lovable are generating fully deployable, full-stack

Critical Database Checks Before You Build Before writing your database schema, don't only think about the main tables. Check these too: • Relationships — who belongs to what, and what happens when related data is deleted? • Constraints — required fields, unique values, foreign keys, valid ranges, and enums. • Indexes — which fields will be searched, filtered, sorted, or joined often? • Data lifecycle — create, update, archive, restore, and permanent delete. • Security — passwords, tokens, sensitive data, encryption, and access control. • User states — active, inactive, suspended, verified, deleted, etc. • Transactions — what operations must succeed or fail together? • Concurrency — what happens when two users change the same data at the same time? • Files & images — metadata, size, type, storage, ownership, and deletion. • Soft delete & recovery — should data really be deleted or only archived? • Versioning — do important records need history or previous versions? • Performance — what happens when you have 1M+ records instead of 100? • Retention & backup — how long is data kept, and how will it be restored? • Future changes — can the schema evolve without breaking existing users or data? Simple rule: Don't design a database only for how the app works today. Design it for how the data will behave throughout its entire lifecycle. @CTBEsoftwareengineers

✨Database tip: sharding, and why you should delay it✨ Sharding means splitting one big database into smaller pieces (shards), each on its own server. Every shard holds only part of the data. Sounds great for scale, but it makes life harder: joins across shards get painful, transactions get tricky, and moving data later is a headache. Try these first: 🔹Add indexes on slow queries 🔹Add read replicas for heavy read traffic 🔹Cache hot data (Redis) 🔹Archive old data If you do shard, the shard key is everything. Pick a key that: Spreads data evenly (like user_id) Matches how you query most often A bad key, like country, creates "hot shards" where one server does all the work while others sit idle. Rule of thumb: shard only when a single well-tuned server can no longer handle your data or writes. This is only a heads-up. Do your own deep dive before you build on it. Hope this helps ☺️ @CTBEsoftwareengineers

Here are some free AI resources from Top AI companies you can learn Fundamentals there 𝟭 - 𝗔𝗻𝘁𝗵𝗿𝗼𝗽𝗶𝗰: anthropic.skilljar.com 𝟮 - 𝗚𝗼𝗼𝗴𝗹𝗲: grow.google/ai 𝟯 - 𝗠𝗲𝘁𝗮: ai.meta.com/resources/ 𝟰 - 𝗡𝗩𝗜𝗗𝗜𝗔: developer.nvidia.com/cuda 𝟱 - 𝗠𝗶𝗰𝗿𝗼𝘀𝗼𝗳𝘁: learn.microsoft.com/en-us/training/ 𝟲 - 𝗢𝗽𝗲𝗻𝗔𝗜: academy.openai.com 𝟳 - 𝗜𝗕𝗠: skillsbuild.org 𝟴 - 𝗔𝗪𝗦: skillbuilder.aws 𝟵 - 𝗗𝗲𝗲𝗽𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴𝗔𝗜: deeplearning.ai 𝟭𝟬 - 𝗛𝘂𝗴𝗴𝗶𝗻𝗴 𝗙𝗮𝗰𝗲: huggingface.co/learn hope it helps ☺️ @CTBEsoftwareengineers

The AI Copy-Paste Trap: Are We Forgetting How to Code? 🧐 Let’s be real, everyone is using AI to write code right now. It’s fast, but blindly copy-pasting is the quickest way to lose our core skills. If we just paste and ship, we aren't software engineers ,we're just prompt typists. To keep actually growing your skills this semester, build these habits: Read Before You Run: Treat AI like a junior dev. Read every line. If you can’t explain why it works, don't use it. Refactor & Structure: AI usually spits out isolated, brute-force solutions. Take time to fit it into your project's architecture and clean up the structure. Test & Break It: Plausible-looking AI code hides the worst bugs. Don't assume it works just because it compiled. Write tests and find the edge cases yourself. Own the Code: The real work starts after you paste. If the AI used a new method or design pattern, take 10 minutes to actually learn it. AI should handle the heavy typing so you have time for the heavy thinking. How do you verify AI code before submitting assignments? Drop your strategies below! 👇 @CTBEsoftwareengineers