How Developers Think
That beleaguered form of human known as the software developer has attracted a number of stereotypes over the decades. Introverted, hipster, coffee-drinking, bearded (if male) and in possession of the ability to block anything out while an elusive coding solution is just around the corner. Of course, the variety of developers in the real world is as wide as that of humanity itself. Those who code can be any sort of person.
That said, there are a handful of common mindsets and motivations which are worth keeping in mind when dealing with your in-house code slingers. These are admittedly generalisations, and not all developers will align with the points below. But enough will to make these assumptions worth holding by default.
They Like Hard Work, But Dislike Unnecessary Work
Developers know that they can't always have the latest and greatest tools or language versions. But they resent not being able to make the best use of what they do have. If they have to do work that isn't needed, such as having to follow outdated protocols or "roll their own" algorithms when reliable third-party options exist, their motivation can be affected. It's not laziness, but the drag of knowing that their energy could be spent on far more rewarding tasks.
They Believe The Ideal Job Is A Hobby You Get Paid For
Undoubtedly some developers exist who keep their IT-related talking and thinking strictly between the start and end of the working day. But for a great many more, coding and its related technologies are a part of life, not just work. Developers code, and talk about IT, because they genuinely enjoy doing so. Devoting spare time to it comes naturally, and furthermore, they'd really like their job to be as rewarding as their extracurricular pursuits.
In the real world of work, things are rarely this perfect, but the more "hobby-like" aspects that can be introduced to a developer's working life, the better. What are these? Variety is a major one, as hobbies tend to have an engaging mix of activities. It helps to combine intensive coding with some simple fixes, specification writing or a stint on the support phone.
For Bugs, They Just Want The Facts
Here's what to tell a developer who needs to fix an issue. What should be happening, what's happening instead, how to recreate the bug, and the urgency. That's it. If they have to sit there listening to a tirade about how nothing ever works, they're probably thinking about how they would've had the issue sorted already if they'd been allowed to go straight back to their desk. Nobody like bugs, but most developers would rather not be a lightning rod for managerial angst when one appears.
As for bugs themselves, what looks horrible or disastrous on the app often has quite a simple, easily implemented fix. Conversely, an issue that seems "easily" solvable can have a complex flaw behind it that's very tough to solve. Understanding this when reporting on bugs is a definite help to developers.
They Don't Define Themselves By Labels
Front-end? Back-end? DevOps? These descriptors may be ubiquitous on job ads, but developers tend not to use these about themselves unless they have to. Developers tend to view themselves more in terms of capabilities - what they can do, or could do. They don't think "I am a Java developer, not a Swift developer", but rather "I can develop in Java, and I could develop in Swift."
This helps to explain why so many developers are attracted to new technologies. They see those techs as something they could do, and are motivated to add them to the list of things they can do. While most organisations can't give their developers free rein to pursue all that interests them, there'll be opportunities for developers to try things outside their department if they wish to. Staff absences or a surplus of work in specific areas can provide these.
They're Skeptical Of "Management Intervention"
Want to introduce a "exercise to improve team relations"? The resident developers probably feel that morning chats about RxJS and artificial intelligence with their neighbours, along with friendly general conversation with other staff members, are good enough relations for them. Attempts at measuring efficiency are also unlikely to get a warm reception. I don't know whether any software houses still use the discredited method of counting lines of code to gauge performance, but anyone who does this is guaranteed to be the laughing stock of the development team. Other metrics are not much better, and frankly a nuisance to developers who are trying to focus on their tasks at hand.
Few developers are happy to be micromanaged. Again, it's a distraction from trying to do their job, and it means they have to work on trying to keep someone happy on top of solving development-related problems. Invariably, micromanagers have a very fixed idea of how things should be done, which puts them at odds with developers. Want to be the sort of manager that developers appreciate? Give them leadership, stimulating challenges, confidence in their ability to solve them, and a co-operative approach to resolving problems rather than an adversarial one.
They Want Everyone In On Testing, And Security As Well
Being the only developer in a team who tests is a tough gig. Your own code is covered, but if your colleagues are contributing their untested code to the same project, this weakens the reliability of your tests if the code you've written has to contact theirs. Also, code that's written without tests in mind is just straight-out harder to write tests for. They also want project managers, business analysts and anyone outside the development team to understand the importance of testing and how it can't be done in zero time.
Overall, developers would like testing to be a natural and expected part of the workflow, without feeling that they have to keep pushing barrows uphill in order to do it. What's been said about testing is just as true for security matters. There's no point in being the only developer who's mindful about these.
The Zone Is Real
Developers work with their mind, in much the same way that people in more physical trades work with their arms and legs. In both these cases, when you've settled into an ongoing rhythm of action - known as "the zone" - there's a strong desire to stay there. While developers aren't always in the zone as they code, when they are they'd really prefer not to be interrupted.
Of course, this is unavoidable sometimes, but it's worth being aware of what a developer needs to do to move out of the zone. They have to mentally 'put down' what their mind was hoisting, and switch gears to focus on the topic now at hand. How quickly this is done will differ according to the individual, but it's not uncommon for developers to be so engaged in what they're doing that directing their attention elsewhere is similar to literally waking them up. It's just how their brains work, and a bit of patience is invaluable.
In Conclusion
As pointed out, this has been a list of traits commonly found within the software developer mindset, rather than an assertion that all developers think in those ways. It's also true that these traits can be found in a wide range of professions outside development. But if there's any aspect of how developers think that comes close to being universal, it's that they love what they do and prefer to have an environment which is conducive to performing at their best. The most valuable gift that developers bring to a team, along with their knowledge and technical abilities, is their intrinsic motivation to create. That's worth preserving.