If you tried to hire me as a sysadmin I would politely explain to you that you had misunderstood my skill set.
If you tried to hire me as a front end developer I would less politely explain to you that you needed your eyes checked and your head examined.
There are things that I am good at. There are even things that I am very good at. Systems administration, user experience and visual design are very emphatically not in those categories.
I’m probably more trustworthy as a sysadmin than the average dev, but not a lot. I wouldn’t like to comment on where my visual design skills are compared to the average dev – I’ve worked with plenty of people who have worse, but that’s because the teams I’ve worked in have typically had a bit of a back-end/front-end imbalance.
The point is, there are people who are good at these things, and I love working with them. It’s truly a delight working with good people who have different and complementary skill sets to your own, because you can compartmentalize problems and trust them to handle the parts you’re not good at. The reach of a good team is vastly greater than the reach of the individuals within it, and the reason is division of skills far more than it is division of labour.
But where do you draw the line?
The problem is you can easily get into a pattern of over reliance. If you always work with people who are much better at something than you, you can get into a habit of handing over even the smallest tasks to them. This can be a bottleneck even when you are working with them – your five minute task might take days to complete because the front end or opts team are busy with a major feature and doesn’t have time to do the task you need.
For me, somewhere this really comes out is when I have side projects.
I have a lot of ideas. Sometimes I implement them. The problem is, what will usually happen is that I will implement them and go “Halp! Mike! I can’t make this pretty!”. Mike will then kindly step in and make it pretty for me, but I’ll probably feel like a bit of an ass about it.
The reason is that I’ve got so used to working with Mike and other people who are better at front end than I am that I’ve come to the conclusion that I’m simply not good at all. Design is just a thing I can’t do. A fact which causes me painful limitations but you’ve got to face reality, right?
Except it turns out it’s not really true.
I’m not good at design, but I can put together something entirely functional. With practice I may even upgrade myself from not bad to actually good (I doubt I’ll ever be amazing. If nothing else I don’t care enough to put in the practice).
For example, I did Github Explorer on my own and you know what, it’s fine. It’s nothing original design-wise and it sure isn’t going to win any prizes, but it doesn’t need to. It just needs to look ok and present the underlying idea.
Would it be better given the attention of a dedicated designer and front-end expert? Oh, certainly. But there are a lot of ways to make it better, and it doesn’t really need any of them. It’s fine.
Which I guess is really the core of my point: Knowing the things that you’re not good at is important. Working with people who are good at the things you are not is great, because it expands your reach. But often you are good enough at these things, and if the thing you want to achieve is already within your reach then relying on other people to help you achieve it is unnecessary, and believing that you need to do so will limit what you can achieve when those people are not available.