I'm not the user to whom you directed the question, but I would answer your question this way: Software developers fall along a spectrum between "caring intens

I'm not the user to whom you directed the question, but I would answer your question this way: Software developers fall along a spectrum between "caring intensely about quality" and "only caring that their ticket/assignment gets done, with very little regard to quality". These are the kind of people he or she is talking about. This can manifest in a lot of ways. Lack of effort in creating names, adding to the "messiness" of the codebase in various ways, not coordinating or communicating with team members to do things in a consistent way. In general, being content with "quick and easy" fixes that take less work but cost everyone in the long run. People will notice where you sit on this spectrum. I don't know what domain you'll be working in, what company, even what _kind_ of company. But if you soak in the need to have a high bar of quality, you will be able to find the resources that pertain to your language/tools/domain/etc in order to make high quality software. It just takes time. I could rattle off topics to study from the top of my head, e.g.: - SOLID principles of OOP - Learn the benefit of immutable data - Normal forms of relational databases But the best thing is to get lots of experience. With different projects, different languages, different programming paradigms, OOP vs FP. Good books/articles/tutorials help the most when you're applying them to a real work context. If you constantly seek out wisdom about how to do things better as you do real work, you won't be the type of person your OP was referring to. :-)