Computing, Software and Data Programmes

The common spine of this family is abstraction, algorithms, software, data, systems and security. Yet two programmes in the same family can differ significantly in mathematical intensity, mode of production, professional authority and daily work after graduation.

Learning commonly takes place through coding labs, project studios, datasets and team-development environments. Naming these environments in a brochure is not enough; investigate learner access, time, equipment, supervision and real student work.

The first comparison axis is which computing layer receives the most attention: hardware and systems, the software life cycle, data and models, organisational processes or security. The second is how products are verified. Working code may be insufficient; performance, security, usability, maintenance and ethical consequences also matter.

A learner researching this family should produce three different artefacts: a small algorithm, a data-supported finding and a mini product another person can use. Rather than only operating ready-made tools, record requirements, tests and explanations of failure.

AI is transforming every programme in this family, but programming foundations, mathematics, data quality and systems security do not lose importance. A person unable to evaluate generated output may gain speed while missing serious errors.

Add three universities to one decision file. For each, record first-two-year courses, practical hours, student work, programme accreditation, teaching language and total living cost in the same table. Do not punish unknown information with a low score; mark it 'to be verified'.

Return to this family whenever a new mini trial is completed, YÖK or ÖSYM data changes, a university curriculum changes, or new evidence emerges about the learner's preferred work environment.

Do not evaluate this family only by reading about it. Use a four-week investigation to encounter real modes of work such as algorithm design, data cleaning, test writing and user feedback. The aim is not to choose a programme in one month, but to observe how curiosity, patience and willingness to learn change during authentic tasks.

In Week 1 compare first-year curricula from two programmes. For every course, note the question it addresses, prior knowledge and assessment form. In Week 2 complete the family's mini trial and record not only whether code runs, but also its correctness, security and maintainability. In Week 3 review a student project or practical report; look beyond the result to method, testing and feedback.

In Week 4 move to occupational tasks. From at least three current occupational profiles or task descriptions, extract recurring tools, outputs, communication responsibilities and the cost of error. Decide whether the relationship between programme title and task is direct, indirect or dependent on additional specialisation.

Close the month with three sentences: Which mode of production attracted me most? Which task was more difficult than expected? What course, project, observation or expert conversation would provide the next piece of evidence? A changed answer is not failure; it shows that the research worked.

• Week 1: compare two real curricula and prerequisites
• Week 2: mini trial, error log and second version
• Week 3: student work and laboratory/studio/field evidence
• Week 4: tasks, tools, outputs and work environment
• Close: learner view, evidence gaps and next review date