If it ain't broke, then don't fix it – Software Engineering Principles

[ Readtime: <4m ]

I do not think that taking a college Software Engineer engineering course will help you develop real world software. Let me explain with a few examples.

All Hail Testing

You can write the prettiest code in the world, but without tests, it’s basically a ticking time bomb. Software is non-deterministic after a certain point — the more complex it gets, the more chaotic it gets. Dependencies change, environments shift, someone decides Friday at 5 PM is the perfect time to upgrade a core library. You can’t predict everything, but you can write tests.

Actually, you should write tests first — before the code. Yes, it feels weird at first, like writing a movie review before seeing the movie. But it forces you to think about what the code is supposed to do, not just what you feel like coding. There are all sorts of tests:

• Unit tests (Does this tiny piece work?)
• Integration tests (Do these pieces play nicely together?)
• End to end tests (Does the whole system actually do the thing?)

And don’t just write tests and shove them in a corner. Publish them along with your code. Tests aren’t someone else’s problem — they’re part of your deliverable. If your tests don’t ship with your code, you’re just handing future-you a ticking time bomb and hoping they have better reflexes.

Too Many Cooks shouldn’t spoil the broth

The old saying goes “too many cooks spoil the broth,” but in software engineering, too few cooks means you end up with spaghetti code and a fire in the kitchen. Collaboration is crucial, but it needs structure. A few non-negotiables:

• Continuous Integration (CI): Every piece of code gets tested before it’s allowed into the mainline. No exceptions. That feature you’re working in a different branch? Try to publish unit-tested incremental changes to the main branch, otherwise you might end up in merge hell!
• Design Docs: Before you write a single line of code, write down what you’re trying to do, why you’re doing it, and how you’re doing it. It’ll save you (and your team) from endless meetings.
• Communication: You can’t over-communicate in software projects. Slack messages, comments on tickets, over-explaining in code reviews — all good things. Silence breeds bugs. Document everything you do. Either in comments, commits or as standalone documents. That brings me to my next point.

Readability (Every variable name matters):

Ever read your code after a hot minute, and you have no idea what's happening? I would pick a codebase that’s easy on the eyes than something that’s genuinely well engineered. Let me explain.

In scripting languages like python, it's more easy than ever to compact a block of code into a single list comprehension with inbuilt functions and a walrus operator. For every developer who writes hacky code, you would then need a developer who can unscramble it. Therefore don’t penalize lengthy and code with unnecessary lines. Instead encourage-

• Comments that don’t just reiterate what’s obvious from the code
• Logs and traces. Yes, they are different. Logs indicate the status of something, and traces indicate the path taken to run that piece of code during runtime.
• Variable names should matter as much as what you’re going to name your kids in the future
• Consistency: follow a set of rules within each part of the codebase. Whether it comes to how you write APIs, or tabs vs spaces - consistency beats your individual opinion
• Lastly, keep every class, function, level of abstraction modular. It should do one and only one thing - not more or less.

Don’t Reinvent the Wheel (Unless You Absolutely Have To):

I’m trying to come up with an analogy for this one. Perhaps it is - Only pick as many battles as you can fight. So many big companies have tried making their own product instead of working with existing software. I like to share a popular XKCD comic on this topic:

Writing code is always half the story. You then have to regularly test it, maintain the codebase, take care of releases etc. Even if it doesn’t support all your needs, you can save on so much effort and money when you switch to open source; There’s so many developers who maintain it in their spare time. You could support them instead.

Final Thoughts

Software engineering is so much more complex than writing code. Namely- thousands of moving parts, tight schedules, limitless bugs and annoying customers. While your startup idea might be very promising, it’s very easy to sabotage its future success with bad software principles. Ending with the quote:

Months of testing and bug fixes can save you hours of planning