When I first started my software engineering degree, I thought we'd just learn to write code. C, Python, loops, arrays — the usual stuff.
Then we had a lecture that completely changed how I see IT.
They showed us a picture that broke everything down: the difference between a programmer and an engineer is like the difference between a builder and an architect. They both work on buildings. But one builds a wall, and the other designs the entire structure that will stand for decades.
Today I'm sharing my freshman-year notes on this. Spoiler: being an engineer is harder, but way more interesting.
-
Is There Even a Difference? (Expectations vs Reality)
Imagine someone asks you: "Write a calculator app."
A programmer will sit down and code it in an hour. It'll work perfectly — on their machine.
An engineer will ask 10 questions first:
- Where will it run? Mobile? Browser? Desktop?
- Who will use it? Tech-savvy people or my grandma?
- What happens if 1,000 people click the button at the same time?
- How do we stop someone from entering letters instead of numbers?
A programmer solves a task. An engineer solves a systemic problem — one that will work for years without breaking.
The difference is huge.
2. 7 Principles of a Real Software Engineer (or Why Work Is Not Just Code)
To call yourself an engineer, you need to follow these 7 commandments. I wrote them on sticky notes for myself:
- System Thinking. Software is like a spiderweb — pull one thread and everything falls apart. You can't think only about your own piece of code.
- Modularity. Break big scary projects into small Lego-like pieces. They're 10 times easier to test and fix individually.
- Architecture First. Never touch the keyboard until you've drawn a diagram on paper. It's like building a house without a blueprint.
- Standardization. I used to think this was boring, but it's actually the language everyone speaks. Ignore it — and nobody will understand your code.
- Documentation. My least favorite part, but the most important. Without docs, your code is just text. With docs — it's a product.
- Reusability. Don't reinvent the wheel. The internet has almost everything — take it and adapt it to your needs.
- Automation. Set up robots (tests, CI/CD pipelines) to do the boring, repetitive work for you. And track your mistakes using metrics.
3. Let's Make It Practical: Airline Tickets and My Project
Our professor gave an example I'll never forget: a flight booking system.
- The coder approach: Build it fast and cheap. It works fine for 10 users. But when 1,000 users try to buy tickets at once — it crashes. Everything freezes, money is lost, and hackers steal data.
- The engineer approach: First, design the entire structure. Create separate modules for users, payments, and airline connections. Plan for security and massive traffic from the start. The result? A system that works for years and handles millions of visitors without breaking.
I looked at my own student project after that lecture and realized — I'm still a coder. But I really want to become an engineer.
Conclusion
That's what software engineering looks like through the eyes of a first-year student. It turned out to be not just "writing code" but about thinking, designing, and taking responsibility for the long-term.
Do you notice the difference between "just making it work" and "making it reliable"? Which approach do you prefer? Let me know in the comments!
And if you want me to share more notes on architecture and development models — leave a tip or a like. I have plenty of notes left, and I'm happy to share them.
#softwareengineering #programming #coding #webdevelopment #productivity #techcareer #engineeringprinciples
