My entirely subject opinion. Those that self-identify as programmers may or may not be current HS or undergrad students. They often know a single language mode

My entirely subject opinion. Those that self-identify as programmers may or may not be current HS or undergrad students. They often know a single language moderately well, maybe a second. Though they know the language, they often don't know what is available to them in the language of choice's standard library, so they often fall victim to re-inventing the wheel. A developer has a few seasons under their belt. They may know several languages, and even have a fair grasp upon what the standard library of those various languages offer and so less likely to reinvent the wheel (although they still sometimes do). They're more likely to have a larger toolbox and decent grasp on when it's reasonable to use a certain tool (language or framework to tackle a new problem). An Engineer is more likely to involve tools to solve problems. Got a performance problem? Going to profile instead of running by gut feel. If your company can afford it, vTune is a great tool here. Engineers are more adapt and comfortable using tools such as gdb, valgrind and strace on Linux or say Windbg on Windows. Bonus: they usually don't need to refer to the manuals to specify the correct commands or interpret the results. This doesn't come from accident or pure reading - you have to have real world practice and experience to know when and which tool is appropriate for the problem at hand. The Senior Engineer knows all of the Engineer as I've briefly outlined above, but also takes the time to teach/mentor/coach the juniors around him or her when they see room for improvement in the junior. And this should not be in the form of "you're doing it wrong, do this instead", but there should be a "why" component in the "you're doing it wrong".