"Re-read your code frequently."
And who does not ?
"I was able to write substantial programs (thousands of lines) and run them without compile or run-time errors on the first try" LMAO :) I believe that :D
Don't write bugs
71–80 of 113 posts
Re: Don't write bugs
#72What if the requirements for the program were wrong and you wrote it correct to specification. Is that a bug if product teams deem it so later? That would require later debugging.
Re: Don't write bugs
#73The term "bug" is kind of overloaded at this point. It would be more useful to talk about different classes of software defects:
- Incomplete/ambiguous specification
- Unhandled IO errors
- Unbounded buffers/memory, unhandled OOM errors
- Defects introduced by state mutation
- Defects introduced by concurrency
- Lack of idempotence
- Lack of back-pressure
- Non-determinism
- API changes
- Low performance
Only some of these can "not be written", and only a few can "not be written" in actual code.
Most have to be solved at another layer (the implementation language/tools, the network, the database, the system architecture at large, design documents or team organisation).
Re: Don't write bugs
#74Aftee a decade as a professional developer, the key practice I've found that makes all the difference is this: make it very difficult for someone using my code to use it wrong. Because no matter how well I write my code, I'm just one developer in a much larger system.
An example: imagine I have an API that takes in a users tax id. In the US, let's presume that's an SSN. In Canada, a SIN. In Brazil, a CPF/CNPJ, and so on.
One option is to give a free form field that let's you say country id and tax ID. Simple, works for all countries, extensible later, no problem. Except that okay, in Brazil we also need a tax address. Fine, add an address field as well. But now when a user is using this API to submit Canadian tax numbers, there's a field for tax address. What's that? Do I need it? I guess I'll give the users home address? And a developer trying to submit Brazilian tax IDs sees that the address field is optional, so I guess I don't need that. ("Why didn't they read the docs that said it wasn't in this case?" Because no one does!).
I've made it possible to use this API incorrectly. I did it to save myself effort and blamed the other developer for using it wrong.
On the other hand, if my API had a different input type for each country's tax ID, with required fields saying they are, it becomes impossible to use it wrong. You can't have a bug, a mistake, because the type enforces correct usage. Go even further and have the constructor for the input type for that county explicitly require the fields it must have, and now you're really making it hard to do it wrong.
Types are powerful tools to prevent bugs. A bug caught sooner is less expensive to fix, and how much sooner can you get than "the moment you wrote it"?
Re: Don't write bugs
#75Would Henry Ford tax programmers for the time they spent debugging?
Re: Don't write bugs
#76Use tools that make it harder. Immutable datastructures, side effects constrained to a few places, good static typing etc. Where I worked before we had 100k LoC Elm projects with virtually no bugs. Now I'm working in a python/django codebase with probably thousands of small hidden bugs.
One thing that helps me a lot is: fail fast. You program must break when something is not right because shitty lasts forever. Immutable objects are great but you need to validate them when you construct them and throw an exception when something is not right. And functions should return what you would expect. For example, this: function GetEntitryById(int id):Entity { var entity = [action to get an entity]; if(entity…
Or use Option/Maybe or Either to represent this and let callers explicitly handle this rather than catching an exception. Is an entity not being found truly an exceptional case?
Re: Don't write bugs
#77Superficially, "Don't write bugs" really only translates to "don't be sloppy, if you're aware of ways that your code will fail in edge cases, handle those edge cases. Develop techniques and habits that will avoid bugs, like better encapsulation."
However, "Don't write bugs" is a joke for a seasoned programmer who's had to work with political constraints. Bugs often arise from major design flaws that can't be fixed in an afternoon. Other bugs arise from management compromises to meet a deadline or price point. Even worse, some bugs arise from problems with external APIs that are completely out of a programmer's control. At this point, "don't write bugs" can really only translate to trying to defend against corner cases that are impractical to fix.
"Impractical to fix," meaning, fixing the bug requires navigating politics. This could be working with a vendor to fix a broken API. It could also be working with management to allocate time to refactor a defective design.
Also: There are poor programmers who just can't "Don't write bugs." They can't think through edge cases; or a fundamentally incapable of understanding edge cases that lead to bugs. (And handling these kind of programmers is a different topic altogether.)
Re: Don't write bugs
#78Earlier quoted context omitted.
In the grand scheme of things Java is a modern language although I dislike how generations of langauges are defined. But the innovation Java brought is larger than what younger languages bring to the table. You can still dislike the language of course.
One of the great ways of avoiding bugs is to make invalid states unrepresentable. An easy win is to use sum types for the various different flavours of a valid input parameter. The verbosity of having to manually create classes, wrap/unwrap rather than defining at-hoc in-place, and pattern matching leaves it in still the not modern camp, among other things.
On making illegal states unrepresentable - this was my favorite post on that topic: https://fsharpforfunandprofit.com/posts/designing-with-types... (I don’t even write F# myself)
Re: Don't write bugs
#79Don't be poor. Just don't. It's really draining. Oh, there are other complex systems at play? Hmm... Still though, avoid it when you can. One piece of advice is to make money.
Re: Don't write bugs
#80This is so funny. I can’t even.
It’s true that you can write code that has no bugs that would be relevant in a programming contest. And that you can avoid the kinds of bugs that you’d find if you read your code 2-3 times.
But if you write code that has to live for a long time, on a lot of devices, used by a lot of people, and that gets attacked by adversaries, then you really start to appreciate the inevitability of bugs even in code that seemed flawless.