Üniversite mi, bölüm mü

2024 YKS üniversite tercihleri ile ilgili son günlerde izlediğim iki videoda "seçim yaparken üniversitenin kalitesi bölümden çok daha önemli" vurgusu yapılınca (video 1, video 2) 27 yıllık mühendis olarak bu yazıyı yazma ihtiyacı hissettim. Bölümden ziyade üniversiteye önem vermenin artılarından bahseden çok da eksilerden bahseden yok.

İyi üniversitelerin en çok vurgulanan faydaları öğrenci kulüplerinin fazla olması, etkileşimde bulunacağın insanların kalitesi ve üniversite networkünden yararlanmak. Burada söylenmeyen husus mezun olduktan sonra kendi okuduğun bölümün dışındaki öğrencilerin profesyonel anlamda sana pek bir faydasının dokunmayacağı. Örneğin Hacettepe öğretmenlikte okurken toplulularda mühendislik ve tıp öğrencileri ile arkadaşlık edebilirsin ama mezun olduktan sonra onların sana iş konusunda destek vermeleri ne kadar mümkün? Bölümden arkadaşların ise staj ve iş bulmana yardım edebilirler, iş yaşamın boyunca onlara danışmaya devam edebilirsin.

Bu arada mühendislik okurken topluluklarda vakit geçirme imkanın az, ben üniversitenin tadını mezun olduktan sonra çıkarabildim, okurken bahar şenlikleri uzaktan duyduğum hoş bir sada idi.

Aileler üniversite adının prestijini kullanmayı seviyor, genelde "bizim çocuk ODTÜ'de okuyor" denir, bölümden bahsedilmez pek. Öğrenci de üniversite sınav badiresini atlattıktan sonra bu itibardan yararlanmak ister. Ama aynı aileler mezuniyet sonrası çocuklarının iyi bir işte çalışmasını daha çok ister. 

Klasik öğrenci hayalleri: "kötü bölüme girsem bile kendimi geliştiririm, yazılım öğrenirim, yüksek ortalama tutturup daha iyi bir bölüme yatay geçiş yaparım, çift anadal yaparım." Bunları başarma olasılığın çok düşük. Bir yıl daha sınava hazırlanmaya mecalin varsa ve "mezuna kalır ve başarı sıralamamı ciddi oranda iyileştiririm" diyebiliyorsan şansın daha fazla.

Geleceği parlak bölümlerin sayısı az. İyi üniversite hevesi ile önü kapalı bir bölümü seçersen pek çok işe başvurman bile mümkün olmaz. İş ilanlarında üniversite adının yazıldığını ben hiç görmedim ama istenen bölümler mutlaka belirtilir.

Örneğin 25K sayısal başarı sıralaması ile Ankara'da devlet okulunda mühendislik istiyorsan ODTÜ Petrol Müh., Hacettepe Kimya Müh. veya Gazi Bilgisayara girebilirsin. Eğer aslolan üniversitedir diyeceksek ODTÜ Petrol'ü yazman gerekir. Bilgisayardan mezun olduğundaki seçenek bolluğu ile petrol veya kimya mühendisliğinden mezun olduğundaki seçenek darlığını dikkate almanı öneririm.

Kritik soru şu: Önündeki 4 yılı mı optimize etmek istersin, 40 yılı mı? Tavsiyem üniversite gözetmeksizin başarı sıralamana uygun bilgisayar mühendisliği bölümlerini yazmandır, nedenlerini daha önceki bir yazımda açıkladım.

Müzik: Europe - The Final Countdown

Matematik'te ezber yerine mantık yürütme

Dün oğlum 8. Sınıf Master Matematik Soru Bankası'ndaki Ünite Değerlendirme-5, soru 7'nin çözümünü tam anlamadığı için bana sordu:

Sorunun cevap videosunda üçüncü kart olarak BC=16cm çıkması durumunda birden fazla üçgen oluşturulabileceğini, bu nedenle olasılığın 3/4 olduğunu söylüyordu. Birden fazla üçgen oluşması için öne sürülen argüman tek üçgen için bir açı ve iki komşu kenarının bilinmesi gerektiği, eğer açının (soruda C açısı) karşısındaki kenar (16cm) verilirse tek üçgen belirtmeyeceği idi.

Oğluma soruları mümkün olduğunca kural ezberleyerek değil, mantık yürüterek çözmemiz gerektiğini hatırlattım ve şu yolu izledim:

1. A merkezli ve 16cm yarıçaplı bir çember çizersek bu çember C'den geçen ışını iki noktada (B ve D) keser.
2. 16cm AC'den (14cm) fazla olduğundan ikinci kesişim C köşesinin üst kısmında kalır (D noktası).
3. Sorudaki üçgenin oluşabilmesi için çember kesişimi C'nin altında olmalıdır (B). O da ancak bir nokta olabileceğinden üçüncü kartın BC=16cm çıkması durumunda dahi tek üçgen oluşur.
4. Cevap çözüm videosundaki 3/4 seçeneği değil, 4/4 = 1 seçeneği olmalıdır.

AB verildiğinde C noktasının altında iki kesişim, yani iki üçgen olasılığı ancak AB'nin AC'den az ve BC kenarına ait yükseklikten (h) fazla olması durumunda mümkün, bkz. aşağıdaki B1 ve B2 noktaları. AB uzunluğu yükseklikten de az olursa kesişim olmayacağından üçgen oluşmaz. AB yüksekliğe eşit olursa yine tek üçgen oluşur.

Kanban vs. Scrum

Kanban is highly flexible with no fixed timeframes. In Scrum, work effort has to be estimated and organized into fixed-length iterations, known as sprints, typically lasting 2-4 weeks.

Kanban is better for projects with changing priorities, while Scrum is more suited for projects with defined requirements and deliverables. If continuous delivery is essential, Kanban might be the better choice. For projects benefiting from iterative development, Scrum is preferable.

For the type of work I am doing, I prefer using the Kanban method, incorporating daily stand-up meetings where each person speaks for no more than 5 minutes. This ensures that everyone stays focused and that efforts are concentrated on high-priority issues.

The Case Against Education

"The Case Against Education: Why the Education System Is a Waste of Time and Money" by Bryan Caplan argues that a significant portion of education is not about acquiring useful job skills, but rather about signaling to employers. Caplan suggests that much of education's value comes from the signal it sends about a student's intelligence, conscientiousness, and conformity, rather than from the skills and knowledge they acquire. He believes that this signaling explains why employers value degrees even in fields unrelated to the job. Caplan also argues that this focus on signaling leads to a waste of resources and time, as students are made to learn subjects that are not directly useful to their future careers. He suggests that a more efficient educational system would focus more on vocational training and less on traditional academic education. He dispels many arguments that are taken for granted by looking at actual numbers.

Outsourcing software development

When outsourcing parts of a software development project, you'll need to overcome several challenges:

Clearly Define the Problem and Verification: It's essential to have a detailed design and create prototypes for testing your ideas before writing a statement of work. The outsourcing partner mainly contributes in terms of usability and maintainability, i.e. they should convert the proof of concept that can barely be used by experts to a product that can easily be used by normal people.

Identify Reliable Partners: This is arguably the most challenging step. In the software world, many claim expertise – after all, it's just coding, right? However, the ideal scenario is knowing firsthand that the team or individuals you're considering are truly capable of handling the project. If you are not sure, starting with small scale (~1 week) discovery projects (free of charge) will be helpful.

Manage Budgetary Constraints: As costs rise, so does the bureaucracy and the number of required approvals. One effective way to control cost is to narrow the project's scope and build on top of open source. While it's imperative to obtain the source code from your partner, consider handling documentation, formal verification and maintenance internally.

By adhering to these guidelines, you maintain control over the project and its future maintenance. You also gain access to top-tier talent that might not otherwise join your team, all while potentially reducing costs compared to in-house development.

Cybersecurity

When deciding on the level of cybersecurity rules to enforce, there is always a tradeoff between security and cost (money and more importantly workplace efficiency). Since 100% cybersecurity is not possible, risk tolerance becomes important.

The first step of cybersecurity is identifying the threat: Are you trying to prevent middle school kids from gaining root access to your servers or do you have national security agencies in mind? Are you trying to prevent data leakage or data corruption? If you want to minimize leakage, is your data really worth the protection cost? People confuse value with secrecy. Something valuable does not make it automatically secret. Many things in life are valuable but not secret. In my experience, the real secrets are far less than what is commonly claimed. Classifying threats and security levels requires individuals who are both experts in security and are aware of its costs. Good luck finding them. Your typical security advisor has a vested interest in scaring you enough to sell you expensive products.

Risk averse managers lean on more and stricter rules. Managers become risk averse when the expected value of taking risks is low for them personally, i.e. when managers are punished when a risk is realized but not rewarded enough when the benefits of taking risks are reaped. In other words, when loyalty is more important than competency.

What is worse is that stricter rules may create the illusion of security (Security Theater) but can actually decrease it. For example, if you force employees to change their passwords every week, they will use more predictable passwords and even write them on Post-its and attach them to the side of their screens!

In such an environment, the cost of lower efficiency almost never comes up in management meetings and that cost is passed on to the lower level managers and engineers. If you are a software developer, your build times increase and sometimes fail. You have to spend a week to find out that the security software was blocking it, and inform the IT department to make an exception for your build. Since software is an ever changing field, you face such problems regularly. If there is a security breach, individuals are held responsible and the system is never questioned. In the long run, this causes longer shipping times, low quality, low morale and loss of personnel. In short, less security and less value to secure...

You have to make peace with the fact that a security breach will eventually happen, similar to earthquakes. What I propose is to use a minimal set of malware scanners and to focus on preventing data corruption by having good backup systems in place. Regulary check that you can build back your system from those backups so that a corruption will have minimal impact.

For more, see my previous posts.

Filtering software product ideas

A typical response I get from people when they learn that I am a software developer is, "I have this app idea X, does it have potential? Would you be willing to implement it?" In software, any idea can have potential, so dismissing it outright is not logical. My default answer is, "That's a fine idea. If you write a concept of operation document detailing how the app will be used and why it would be useful, I promise that I will design and code your first version (MVP) for free," and I genuinely mean it.

This approach benefits me in three ways. Firstly, by refraining from saying 'no', I show respect for their ideas and creativity, thereby avoiding potential hurt feelings. Secondly, it allows me to focus on truly promising and well-thought-out projects, rather than getting bogged down in evaluating every idea that comes my way. Lastly, if an idea does prove to be good, I gain the opportunity to create value.

However, despite my promise to work for free, I rarely receive a concept of operation document. It's easy to have an idea but difficult to write it down. Also, when writing it down, they think more about it and usually realize that it wasn't as impressive as they initially thought.

Music: Damon Albarn - Sister Rust