Other Software Engineering Principals

…that for some unknown reason, they don’t always teach you at University.

Learn clean code patterns not (just) frameworks.
Frameworks change every few months. Some last for a while but even they change dramatically. Focus on learning the concepts of clean, re-usable, operationally efficient code. This is transferrable to other frameworks. Nobody uses jQuery in 2022. Clean code is still critical. On the subject of clean code…

Uncle Bob is your friend.
Make sure you understand the concepts from Clean Code: A Handbook of Agile Software Craftsmanship. It’s still super-relative all these years later.

So are Google, StackOverflow and your colleagues.
Attempt a problem first. Set a time-limit to solving it. After that point search online for the problem, including any error codes, keywords etc. Set another time-limit. Now ask colleagues, friends, leads, explaining the problem and what you’ve done already.

If you have to use cache, do it at the end.
Caching isn’t a cure-all, it can be complex to invalidate and it’s not always more efficient. Optimise your code first. Then if you truly need caching, cache. Set a benchmark beforehand of the code without, then after implementing the cache and ensure it is actually faster, as it isn’t always the case.

Do you really need that line of code / package / library?
If not, turn it off. The amount of times I’ve seen scenarios such as including the entire underscore package (just for the deepClone method) is incredible. Additional packages can increase overhead, bring additional security risks, add to the bundle size of UI projects, add to install/build times and more. Applies to code, internal files, packages etc.

JS Example: Axios / SuperAgent are pretty much just fetch with a few extras. If you don’t need the extra bits, don’t use them.

If it ain’t broken, don’t fix it.
Surely you have more exciting things to do? Sometimes refactoring can actually make situations worse. Go build something new!

Avoid Hasty Abstractions by Keeping it Simple (Stupid) AHA x KISS
Abstracting code well, is hard. If you don’t actually need to abstract it, if you only have one current use-case for that code, why waste your time? On top of this, you may not know yet how the code may be re-used, so your abstraction may be incorrect anyways. When you do see a second or third use-case for that snippet of code, refactor here, with the additional knowledge of how this code could vary.

Deliver only the functionality required, to a high standard.
“KISS”.”AHA”. “If it ain’t; broken…”, “Do you really need it?” Can you see a pattern yet?

So many times, I’ve seen pull requests/merge requests/tickets/entire projects delayed because instead of doing the required functionality, the engineers are going above and beyond to add extras. Deliver the basics first. Then iterate. This way you’ll deliver on time & enhance if you have time. This is how you be the best friend of your Project Manager / Lead and make your life miles easier.

Good communication + good code is often better than great code and poor communications.
I’ve managed teams for over a decade. I’d take a good coder who communicates clearly over a great coder who doesn’t communicate as well.

Update your team / project manager / ticket as its status changes. When you pick it up, if you encounter a blocker (after trying to solve it first), let the team know. When you’ve completed it ready for review. If you see the estimates are askew. Just be honest and open. Makes it easier for your team to organise especially at scale. You’ll be appreciated, even if it’s bad news.

Keep learning. Forever.
You don’t want to be the engineer in the background, complaining about how it was better in the olden days of jQuery, Macromedia Dreamweaver and Paint Shop Pro 5, while the newbies smash out lightning fast web apps using React in a matter of hours.

I find that Udemy does the most up to date tech courses, often on sale for ~£14. Youtube has some great smaller chunk videos for free too. 20 years of coding and this year, I’ve been learning:

Every programming “rule” ever, is a guide, not an absolute rule.
Except this one, naturally.

Don’t take my word for it.
AHA – Kent C Dodds
KISS – Wikipedia
You’re probably wrong about caching – Mike Solomon
Stop learning frameworks – Eduards Sizovs
Clean Code: A Handbook of Agile Software Craftsmanship – Robert Martin

One thought on “Other Software Engineering Principals

Leave a Reply