What is the 'developer philosophy' of software developers?
Science fiction writer and software developer
Developer philosophy @ Things Of Interest
https://qntm.org/devphilo
According to qntm, he had the opportunity to talk about software development philosophy to novice developers at work, and he thought it would be worthwhile to write down the content in more detail. The following seven points were listed by qntm as his philosophy.
1: Never get into a situation where a 'rewrite from scratch' seems appealing
It's generally understood that starting over from scratch is not a good idea. So qntm takes a step back and points out that if starting over seems appealing, an unavoidable mistake has already been made.
As warning signs to watch out for, qntm listed 'increasing technical debt,' 'difficulty in making seemingly simple code changes,' 'difficulty in documenting and commenting code,' 'difficulty in onboarding new developers,' 'fewer people who know how a particular area of the code base actually works,' and 'appearance of bugs that no one understands.' He said the risks of rewriting from scratch are avoidable.
2. Aim to get 90% of your work done in 50% of the time you have available
Regarding the saying whispered in software development circles that 'the first 90% of the work takes up 90% of your time, and the last 10% takes up 90% of the remaining time,' qntm said, 'It's a bit funny, and absolutely based on fact.'
Writing code and getting it to run takes time, and once you get it running, you can say that 'the job is half done.' On the other hand, there is still work to be done, such as refining the code, maintaining it, and documenting it, which, if skipped, will result in poor functionality and incompleteness. Also, writing the code itself can cause unexpected problems.
qntm suggested that if you realize you don't need the extra time, use it to implement process improvements or pay down technical debt.
3: Automate good habits
When something arises that all developers participating in a project should start doing, such as 'there is a new best practice' or 'a new tool has been introduced that needs to be used consistently,' or when something arises that all developers should stop doing, such as 'we have decided to stop using a method or API,' there are two ways to change the overall behavior of the developers.
One way is to reach out to everyone one by one, or to communicate directly with everyone in a team meeting, send an email, or add new guidelines to the wiki or README of the repository.
The other way is to automate it.
However, qntm pointed out that automation is not a perfect or universal solution, and there are many software and abstract technical requirements that cannot be automated, and that creating too many arbitrary rules can make operation difficult. He then summarized, 'If you find yourself repeatedly saying, 'I forgot to do XX, so make sure you always do XX,' it may be time to automate XX.'
4. Consider extreme data
Your code needs to handle all possibilities: what if the request fails or hangs forever? What if you're returning just one byte per second for an hour, and the table you're displaying has a million rows? What if it has a billion rows? What if the name has a slash in it, or a trailing space in it, or is 1MB long? qntm says 'If you tell me you can prove that a string is non-empty, I wouldn't believe you.'
5: There is usually a simpler way to write it
qntm quotes the old chess adage 'When you see a good move, look for a better one' and the unsourced quote 'Sorry for writing you such a long letter, but I didn't have time to write you a shorter one.' He says that if you can block out your time properly, you can take the time to see if there's a way to do it better by 'getting 90% of the work done in 50% of the time you have available.'
6: Write testable code
This means 'well-defined interfaces and minimal side effects,' qntm said, and code that's hard to test is probably not properly encapsulated.
7. It’s not enough for code to be “obviously correct” – it must be “obviously”, “visibly” and “trivially” correct.
Some code may work by chance, but that's because 'situations where bad input would cause it to fail' are precluded by the structure of other code around it. 'I hate this,' qntm says, explaining that even if technically it's bug-free, it's difficult and dangerous to reconstruct other code.
It seems that qntm had another philosophy, but he has forgotten it.
Related Posts:
in Note, Posted by logc_nt