Software Engineering Principles

As we hustle through our tasks – coding, testing, deploying – it’s crucial not to overlook the engine that powers our work: Data Structures and Algorithms (DSA). Sure, we might push them aside, thinking, "I'll get to it later," but let me tell you, those "laters" can become "nevers," and before you know it, we’re in a pinch! Take sorting algorithms as an example. They're the bread and butter of efficiency in code. Look at Bubble Sort – it's like organizing books on a shelf, one swap at a time, until it's just right. Or Quick Sort, which slices a list like a skilled chef until everything’s in its perfect place. I get it, we didn't all study DSA in depth, and gaps can appear, especially when performance tuning or complex logic comes knocking on our door. But remember, a solid grasp of basics like arrays, linked lists, and not to mention trees and graphs, along with algorithms like sorting and recursion, truly round out our engineering toolkit. Interviews are rife with DSA questions, and I’ve seen many a seasoned developer falter. It’s those little hours of DSA revision that could've made all the difference. So, my two cents? Carve out a little time each week. Crack open those DSA books, hit up some YouTube Videos and reacquaint yourself with the concepts that are the pillars of our coding world. By keeping your DSA skills sharp, you’re not just avoiding a potential interview pitfall; you’re equipping yourself with the knowledge to tackle problems head-on and with confidence. Stay curious, stay sharp, and never underestimate the power of the basics. They might just be what sets you apart from the crowd.

Last night, I was chatting in the hotel bar with a bunch of conference speakers at Goto-CPH about how evil PR-driven code reviews are (we were all in agreement), and Martin Fowler brought up an interesting point. The best time to review your code is when you use it. That is, continuous review is better than what amounts to a waterfall review phase. For one thing, the reviewer has a vested interest in assuring that the code they're about to use is high quality. Furthermore, you are reviewing the code in a real-world context, not in isolation, so you are better able to see if the code is suitable for its intended purpose. Continuous review, of course, also leads to a culture of continuous refactoring. You review everything you look at, and when you find issues, you fix them. My experience is that PR-driven reviews rarely find real bugs. They don't improve quality in ways that matter. They DO create bottlenecks, dependencies, and context-swap overhead, however, and all that pushes out delivery time and increases the cost of development with no balancing benefit. I will grant that two or more sets of eyes on the code leads to better code, but in my experience, the best time to do that is when the code is being written, not after the fact. Work in a pair, or better yet, a mob/ensemble. One of the teams at Hunter Industries, which mob/ensemble programs 100% of the time on 100% of the code, went a year and a half with no bugs reported against their code, with zero productivity hit. (Quite the contrary—they work very fast.) Bugs are so rare across all the teams, in fact, that they don't bother to track them. When a bug comes up, they fix it. Right then and there. If you're working in a regulatory environment, the Driver signs the code, and then any Navigator can sign off on the review, all as part of the commit/push process, so that's a non-issue. There's also a myth that it's best if the reviewer is not familiar with the code. I *really* don't buy that. An isolated reviewer doesn't understand the context. They don't know why design decisions were made. They have to waste a vast amount of time coming up to speed. They are also often not in a position to know whether the code will actually work. Consequently, they usually focus on trivia like formatting. That benefits nobody.

Most of us review code in the wrong order. We spot a missing test or a style inconsistency before even asking whether the code is correct. We should think about it differently. The first question should always be: Does this code do what it is supposed to do? If the answer is no, nothing else matters. Style, structure, tests - all secondary to correctness. Once you are confident it is correct, ask if it is clear. Can someone else (or you, six months from now) understand what is happening and why? Clarity in code helps ensure it does not become a liability. Then check whether it matches the style and conventions, because inconsistencies add cognitive load for everyone who reads the codebase afterward. After that, look for duplication. Is this solving a problem that is already solved somewhere else? Could this be a shared utility? Finally, ask whether it is well tested. Not just "are there tests" (non-sensical ones), but do the tests actually cover the meaningful cases? Correctness. Clarity. Style. Deduplication. Tests. In that order, every time. Hope this helps.

Dear Software Engineers, If your app serves 10 users → a single server and REST API will do If you’re handling 10M requests a day → start thinking load balancers, autoscaling, and rate limits /— If one developer is building features → skip the ceremony, ship and test manually If 10 devs are pushing daily → invest in CI/CD, testing layers, and feature flags /— If your downtime just breaks one page → add a banner and move on If your downtime kills a business flow → redundancy, health checks, and graceful fallbacks are non-negotiable /— If you're just consuming APIs → learn how to handle 400s and 500s If you're building APIs for others → version them, document them, test them, and monitor them /— If your product can tolerate 3s of lag → pick clarity over performance If users are waiting on each click → profiling, caching, and edge delivery are part of your job /— If your data fits in RAM → store it in memory, use simple maps If your data spans terabytes → indexing, partitioning, and disk I/O patterns start to matter /— If you're solo coding → naming things poorly is just annoying If you're on a growing team → naming things poorly is a ticking time bomb /— If you're fixing bugs once a week → logs and console prints might do If you're running production → you need structured logs, tracing, alerts, and dashboards /— If your deadlines are tight → write the simplest code that works If your code is expected to last → design for readability, testability, and change /— If you work alone → "it works on my machine" might be fine If you're in a real team → reproducible builds and shared dev setups are your baseline /— If your app is new → move fast, clean up later If your app is in maintenance hell → you now pay interest on every rushed decision People think software engineering is just about building things. It’s really about: – Knowing when not to build – Being okay with deleting good code – Balancing tradeoffs without always having all the data The best engineers don’t just ship fast. They build systems that are safe to move fast on top of.

Well - the final draft of the Code of Practice for general-purpose artificial intelligence models is out. On its face, it appears to be a voluntary, self-regulatory initiative encouraging best practices around copyright and AI training. But... The final text, along with new statements from the EU, shows that the Code is closer to a soft mandate. Far from offering clarity, its release highlights how much work is left to be done in Europe’s AI regulatory structure. The Code is far stricter than earlier drafts. Language once referring to “reasonable efforts” has been replaced with binding commitments. Developers must now exclude infringing websites from training data and apply safeguards to stop models from generating outputs that reproduce protected content. They must respect machine-readable rights signals like robots.txt. Crucially, the final text confirms that open-source models are not exempt and OS developers must include documentation warning users that copyright-infringing uses are still prohibited. While the final draft of the Code strengthens obligation wording, it removes the one provision that required developers to assess the legality of third-party datasets. Measure I.2.4 would have obliged them to make basic efforts to verify whether datasets obtained through means other than web crawling were lawfully compiled. Well. It’s gone. This omission creates a large compliance gap. If a signatory scrapes content themselves or commissions someone to do it, obligations apply. But it seems if they purchase a dataset from a third party, there is no obligation to check its origin. In an industry reliant on massive troves of unclear content, that is a notable concession. But wait - there’s more! The Commission’s Q&A confirms that developers who who fall short after signing will still be considered to be acting “in good faith”, and the AI Office will support rather than penalise them. This grace period runs until 2 August 2026, after which fines may be imposed under the AI Act. This sets up a two-tier system. Signatories are shielded for a year, even if non-compliant. Non-signatories are not. So those who do not sign the “voluntary” Code face immediate legal risk. That is not voluntary. It is regulatory pressure disguised as choice. The Code also arrives without critical supports. Although it demands transparency around training data, we still have no template for how disclosures should be made. Article 53 of the AI Act requires developers to publish training data summaries, but no guidelines or minimum content standards have been issued. Nor have the GPAI guidelines been finalised, meaning developers do not yet know how their models will be assessed under EU law. The EU may address these gaps as the AI Act takes effect and the GPAI guidelines are finalised. But for now, this Code is not a definitive rulebook. It is a political compromise, and it leaves critical questions unanswered - especially around data provenance.

Code is the product. How do you prevent a 1M+ LoC Python library, built by thousands of contributors, from collapsing under its own weight? In transformers, we do it with a set of explicit software engineering tenets. With Pablo Montalvo, Lysandre Debut, Pedro Cuenca and Yoni Gozlan, we just published a deep dive on the principles that keep our codebase hackable at scale. What’s inside: – The Tenets We Enforce: From One Model, One File to Standardize, Don't Abstract, these are the rules that guide every PR. – "Modular Transformers": How we used visible inheritance to cut our effective maintenance surface by ~15× while keeping modeling code readable from top to bottom. – Pluggable Performance: A standard attention interface and config-driven tensor parallelism mean semantics stay in the model while speed (FlashAttention, community kernels, TP sharding) is a configurable add-on, not a code rewrite. This matters for anyone shipping models, contributing to OSS, or managing large-scale engineering projects. It’s how we ensure a contribution to transformers is immediately reusable across the ecosystem (vLLM, ggml, SGLang, etc.). Read more on the Hugging Face blog

Some organisations are drowning in technical debt. - A "5-minute fix" turns into 3 days of effort. - Adding new features feels like playing with a house of cards. - That "quick fix" from 2 years ago? Now it runs your entire business. - Every team meeting is a battle: Feature vs. Quality - Your team is getting slower by the month. - A tiny change takes weeks to test It doesn't have to be like this. And 𝗶𝘁'𝘀 𝗰𝗲𝗿𝘁𝗮𝗶𝗻𝗹𝘆 𝗻𝗼𝘁 𝘁𝗵𝗲 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀' 𝗳𝗮𝘂𝗹𝘁𝗅 Usually, it's the result of 𝗺𝗶𝘀𝗽𝗹𝗮𝗰𝗲𝗱 𝗽𝗿𝗶𝗼𝗿𝗶𝘁𝗶𝗲𝘀 and a misguided organizational development culture. Some root causes: - "Just make it work for the demo" - Fixing technical debt rarely gets priority - Immediate deadlines trump long-term code health - Leaders are rewarded for short-term results - Sales teams promising features without consulting engineering - Career advancement based on visible new features - Business leaders don't trust engineering time estimates - Engineers don't trust management's promises to "fix it later" Here are 5 clear, actionable recommendations: 1. Make system health a product feature, not just a technical problem. 2. Measure and demonstrate how technical debt is slowing down your business. 3. Include clean-up time in all feature estimates - no exceptions. 4. Never bypass quality checks, even under pressure. 5. Reward teams for preventing problems, not just fixing them. When technical health becomes part of your product strategy, your teams move faster, your systems stay reliable, and your business grows stronger. Best of all? Your developers come to work - excited to build great things instead of dreading the next fire. - proud of their work instead of apologizing for it. - energized to create instead of stressed about breaking things. "When did technical debt hit your organization the hardest? Share your story below - whether it's a horror story or a success story. 👇 P.S. In Sophie's and my forthcoming book, we share our experiences of how to develop good software sustainably. #devops #technology #qualit

Software engineering principles I keep coming back to: == Code organization == - Files that change together should be placed together - Split vertically, not horizontally - Lasagna code, not spaghetti code. Clear layers, not a tangled mess == Boundaries and abstractions == - Do not let product logic leak into infrastructure code - Minimize API interfaces and expose minimal functionality - Functions should either do one thing well, or glue/orchestrate multiple smaller functions - Abstractions should reduce change surface area, not just hide code == Correctness and maintainability == - Type safety across the entire stack, from database to server to client - Favor pure functions, because they make logic easier to test - Lint rules should either error or be ignored. Never warn == Naming and shared language == - Names should encode intent, not implementation - Standardize terminology and conventions early, ideally through a glossary - Prefer long, clear names over short, vague names, even at the cost of verbosity == Engineering leverage == - Invest in making your tools and workflows fast and robust - Learn design patterns well, but the best way to understand them is by applying them to real problems - Optimize for ease of deletion, not just ease of addition Follow me Yangshun Tay and GreatFrontEnd for more software engineering tidbits.

Software engineers often underestimate how a single line of code can impact the company's profits. And it could be a trivial log line to print information for debugging. 😫 😫 Few years ago, my team was owning an AWS Lambda that worked very well and required minimal intervention. One day my Manager asked me why is the CloudWatch cost $15,000 but Lambda's cost was $1,200 only. 😱 😱 I decided to root cause this issue and finally figured out the main culprit was redundant log lines in the lambda. Eliminating the log lines bought down the costs by 10x. 🚀 🚀 What was the main issue for high CloudWatch costs ? 👉 CloudWatch charges $0.5/GB for ingestion and $0.03/GB for storage 👉 Our AWS Lambda was logging close to 5MB data per second. 👉 It was logging the request and a huge response payload (~100KB) 👉 As a result, the overall log ingestion cost was high. How did we debug the issue ? We used the CloudWatch log metrics to check the data usage. And identified the log group that was resulting in increased bill amount. CloudWatch console tool helped in debugging the root cause. How can we prevent such issue in the future ? ✅ Only log useful information i.e exceptions, critical errors, etc. Avoid logging everything. ✅ Use log levels such as Debug, Warn, Info, Error, etc. ✅  Add filtering to filter only the Error/Warn logs before ingesting into CloudWatch ✅  Review the code carefully and assess the impact of log line on the costs. Treat debug lines like a vulnerability. ✅  Continuously monitor the CloudWatch costs and set alarms to warn the team of any high costs. One of the key takeaways from this story is that engineers must know what impact each line of code will have on the overall business. And accordingly adopt best practices to prevent high costs. In case you have experienced a similar issue in the past, you can post in the below comments what best practices you are following. 👇 👇 #tech #aws #cloud #cloudcomputing