SoftwareEngineering

Tags

Follow from the Fediverse

Follow #softwareengineering from Mastodon or any other Fediverse app and its public posts arrive in your timeline. No vutuv account needed.

@softwareengineering@tags.vutuv.de

Your address is used once, to send you to your own server's follow dialog. It is never stored here.

Posts with this tag

5 posts

Filters
Brain Bug @junior42 norden.social

RIP Margaret

Margaret Hamilton, die das Software-Programm der Apollo-Mission verantwortete und Software Engineering als Ingenieurs-Disziplin begründete, ist immAlter von 90 Jahren gestorben.

MargaretHamilton Apollo Software SoftwareEngineering Pionierin
Schwarzweißfoto einer jungen Frau, die neben einem hohen Stapel aufgetürmter Dokumente steht und lächelt
Misinformation-Superhighwayman @DamienWise aus.social

Vale Margaret Hamilton.
She was a Software Engineer.
She was the first Software Engineer because she defined the term, Software Engineering:
“When I first came up with the term, no one had heard of it before, at least in our world. It was an ongoing joke for a long time. They liked to kid me about my radical ideas. It was a memorable day when one of the most respected hardware gurus explained to everyone in a meeting that he agreed with me that the process of building software should also be considered an engineering discipline, just like with hardware. Not because of his acceptance of the new ‘term’ per se, but because we had earned his and the acceptance of the others in the room as being in an engineering field in its own right.”

Margaret Hamilton led the Software Engineering team at MIT that created the software that ran NASA’s Apollo Guidance Computer. The photo of her standing next to a stack of source code printouts — that’s her work, and she was essential to NASA’s mission of landing people on the Moon for the first time ever and getting them back to Earth again safely.

Margaret Hamilton, computing pioneer who led software development for the Apollo program, dies at 90
news.mit.edu/2026/…

MargaretHamilton SoftwareEngineer SoftwareEngineering ComputerScience NASA
+3 Less MIT Apollo MoonLanding
A B&W photo of a person standing next to a stack of printed paper as high as the top of their head. This is Margaret Hamilton, at work as a Software Engineer and the leader of a team of extremely specialised programmers who worked for NASA. The photo was taken in 1969, and it shows a physical form if her work since she joined the Apollo project in 1965 (she joined at the age of 29 by my calculation). My interpretation of the expression on her face is a mix of pride and mild amusement.  She has glasses, long, straight hair, and neat office attire. Margaret Hamilton has her hands placed gently on the stack of printouts to keep it all balanced upright. The pages appear to be arranged in bundles, ranging from 8-10 centimetres thick, to 20cm thick or more. The resulting stack of printouts is physically impressive for being an unusual feat, and it represents something even more impressive: it's the printed form of the source-code she and the team she led wrote for the NASA Apollo project. Their software ran on the Apollo Guidance Computer that was that on board each Apollo command module and Apollo Lunar Module. The Apollo Guidance Computer onboard the Eagle was an essential flight instrument for Neil Armstrong when he piloted the craft to land on the surface of the moon.

Wie ich aktuell mit mehreren Coding-Agenten arbeite

Inzwischen merke ich immer deutlicher: Es gibt nicht den einen perfekten Agenten – und vermutlich auch nicht die eine perfekte Entwicklungsumgebung – für alles.

Ich arbeite aktuell vor allem mit Claude und Codex und merke dabei, dass beide unterschiedliche Stärken haben.

Claude gefällt mir häufig bei Planung, Struktur und einer ersten Umsetzung innerhalb vorhandener Projektregeln. Codex empfinde ich oft als pragmatischer und direkter und setze ihn deshalb gerne als zweiten Blick oder für Reviews ein.

Dabei ist das aber längst kein fester Workflow mehr.

Je nach Aufgabe wechsle ich zwischen den Werkzeugen und lasse auch bewusst einen Agenten auf die Arbeit des anderen schauen.

Der eigentliche Schlüssel ist gemeinsamer Kontext

Damit das funktioniert, muss das Repository selbst gut vorbereitet sein.

Guidelines, Skills, Projektregeln, Tests und eine verständliche Entwicklungsumgebung werden für mich immer wichtiger.

Denn wenn jeder Agent erst wieder neu erraten muss, wie ein Projekt aufgebaut ist und welche Regeln gelten, verliert man einen großen Teil des Produktivitätsgewinns.

Mein Ziel ist deshalb weniger, den „besten“ Agenten zu finden.

Ich möchte ein Projekt so vorbereiten, dass unterschiedliche Agenten sinnvoll daran arbeiten können und austauschbar bleiben.

Agentische Entwicklung findet für mich nicht nur in Agent-First-IDEs statt

Ich nutze VS Code mit Devcontainern ebenfalls intensiv für agentische Entwicklung.

Der Unterschied ist für mich eher: Dort kann ich den Agenten wesentlich besser auf die Finger schauen.

Ich sehe Dateien, Diffs und die Struktur des Projekts direkt vor mir, kann Änderungen gezielt nachvollziehen und habe stärker das Gefühl, jederzeit eingreifen zu können.

Agent-First-Umgebungen wie Claude Code oder Codex sind dagegen besonders angenehm, wenn ich eine Aufgabe stärker delegieren und den Agenten relativ selbstständig daran arbeiten lassen möchte.

Für mich läuft es deshalb nicht auf VS Code oder Agent hinaus.

Und auch nicht auf Claude oder Codex.

Sondern auf eine Kombination daraus – abhängig davon, was ich gerade erreichen möchte und wie eng ich die Umsetzung begleiten will.

Vielleicht ist genau das die neue Fähigkeit:

Nicht nur Code zu schreiben, sondern für jede Aufgabe den richtigen Agenten, den richtigen Kontext und die passende Arbeitsumgebung zusammenzubringen.

1
From other networks 2

Bei aller Begeisterung für Agentic Coding bleibt für mich eine Frage offen:

Was bedeutet das eigentlich für die nächste Generation von Entwicklerinnen und Entwicklern?

Ich habe darauf keine einfache Antwort.

Denn bei mir selbst merke ich sehr deutlich: Der Grund, warum ich Agenten heute sinnvoll einsetzen kann, ist mein technischer Hintergrund.

Ich verstehe Konzepte, Architekturen und Abhängigkeiten und kann zumindest beurteilen, ob ein eingeschlagener Weg plausibel ist.

Aber was passiert ohne dieses Fundament?

Ich kann mir nur schwer vorstellen, wie es wäre, mit Agentic Coding aufzuwachsen, ohne vorher selbst Code geschrieben, gelesen, debuggt und Systeme von Grund auf verstanden zu haben.

Genau hier sehe ich eine echte Herausforderung.

Ich glaube nicht, dass die Zukunft darin liegt, jede Zeile Code weiterhin von Hand schreiben zu müssen.

Aber wir dürfen auch nicht den Fehler machen, Verständnis durch reine Bedienung zu ersetzen.

Wer Software nur noch über Agenten erzeugt, ohne die Grundlagen zu verstehen, kann irgendwann kaum noch beurteilen, ob das Ergebnis wirklich gut, sicher oder überhaupt sinnvoll ist.

Und daraus entsteht eine weitere Abhängigkeit: von den Modellen, Werkzeugen und Plattformen, die diese Arbeit für uns übernehmen.

Deshalb bleiben offene Technologien und Wissen wichtig

Das betrifft nicht nur einzelne Entwickler, sondern langfristig unsere gesamte digitale Infrastruktur.

Gerade deshalb halte ich offene Standards, Open Source und Wissenstransfer für wichtiger denn je.

Wir müssen die neuen Werkzeuge nicht ablehnen.

Wir müssen lernen, sie richtig einzusetzen – und gleichzeitig dafür sorgen, dass Menschen weiterhin verstehen, was sie damit erschaffen.

Vielleicht ist genau das eine der großen Aufgaben beim Agentic Coding:

Nicht zu verhindern, dass Maschinen uns Arbeit abnehmen.

Sondern sicherzustellen, dass wir trotzdem noch wissen, was sie da eigentlich für uns tun.

2

Keyboard shortcuts

Navigation

Home g h
Feed g f
Messages g m
Notifications g n
Your profile g p
Search /

Actions

Write a new post n
Send the post or message you are writing ⌘/Ctrl ↵
Next post in the feed j
Previous post in the feed k

General

Show this help ?
Close menus and dialogs Esc

The single-key shortcuts pause while you type, and are off on phones and tablets.