Hacker News new | past | comments | ask | show | jobs | submit login

My job is "first level support". I have to analyse problems reported by users and often to read source code to find bugs. I have seen a lot of shitty code and a lot of very clean code, but most of the problems come from shitty specifications. When the requirements reflect a poor understanding of the users need (or a poor sense of logic), whatever the qualities of the developer, the resulting code will always be a maintenance nightmare.



The developers should be able to push back on some of that - and at least document in the code that certain logical inconsistencies were raised but glossed over.

Simply understanding that something will be a maintenance nightmare should inform a developer enough so that they, at the very least, leave useful info/docs about what corners were cut and why. Until you've had to deal with mountains of various legacy projects completely undocumented, you won't even know this is something you should be doing.


I always thought 80% of coding (solving anything really) is understanding the problem.

The other 50% is implementation.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: