I don’t know yet whether I’ll professionally be a developer or a sysadmin. I’d be happy doing either, and I’m going to keep tinkering with both vocations in my personal life. However, I know that in both roles, I’ll need to explain what I’m doing to other people and convince them that it’s valuable.

In a job I held years ago, a Geek Squad type of gig, I was doing this wrong. I was excessively humble, and I failed to convince my boss that what I did was worth the time. I presented it as easier than it was, and I assumed that as another technical person, he would understand the true time and effort cost involved in my work. That wasn’t true. This was made worse by the generational difference between me and my boss. I probably should have taken the hint when I discovered that he had a smartphone but didn’t use it for email and wouldn’t use SMS messages. I lost that job because while I was working hard, I wasn’t convincing my boss of the value of my work and I wasn’t making my work visible to him.

So: don’t do that! As a developer or a sysadmin, you are a specialist. That means that people outside your specialty don’t understand what you do - and very often, that extends to not understanding its value or its difficulty. Speak up. Use a different standard than you do with your peers in your discipline. You have to use the skill-set traditionally associated with sales - and that can be problematic, because “sales” and “advertising,” to technical people, generally mean “people lying and not getting punished for it.” The skills toolbox is still valuable - for technical people, it’s probably best to think of it as open communications and standards. Publish your personal standards, so that everyone who contacts you knows what you need to do and its difficulty level. That openness will help to prevent people from dismissing your effort and considering it trivial. You don’t want people to think that your work is trivial - many problems lie in that direction.

In turn, you and I need to cultivate an awareness that other people’s work is not trivial either. I’m fond of Joel Spolsky’s article about the “Developer Abstraction Layer.” As a specialist, you’ll often be in a position where other people’s effort is invisible to you. That’s good when it lets you get your own work done more efficiently - but bad when it blinds you to the value of others' contributions. Part of the trade-off of specialization is that you are more aware of the difficulty of tasks within your specialization’s problem domain than of the difficulty of tasks outside it - and as a human, you tend to underestimate the difficulty of those extradisciplinary tasks. That is a trap - and it’s another reason to have good communication skills. If you can build rapport with people quickly, it’s less likely that you’ll need to care about the tasks in the problem domain of their specialty. You can trust them just do their work with their specialty and tell you about the results - the same as you do for them.

Specialization is valuable, but don’t let it turn into contempt for those outside your specialty or blind you to the difficulty of tasks in other specialties.