I’ve only encountered a few seekers in my professional career. That said, they stick out like a soar thumb. They are capable of delaying products, finding bugs in perfect code – writing code that looks incredible, but, might miss something obvious. They dig deep into the problem when troubleshooting – and heavily blame others and existing code for any problems. It’s amazing the amount of technical detail they can find within a code base – I’d even consider them genius level in certain areas, but that said, let me cover some strengths and weaknesses and areas of growth – if you find you are a seeker.
Seekers are passionate. It’s a huge asset. They really care about doing things properly, about digging into problems, and providing solutions. They care about their code. Whatever their motivation is, they strive for perfection. If they find they’ve landed in a working culture where that perfection isn’t appreciated, or if they perceive that others are not as focused on doing things properly. They’ll speak out about it. And if they stop speaking out about it – they’re considering leaving. The passion is a huge asset in any dev culture.
Their passion also drives them to know intimate details of how a programming language works. I’m a passionate developer, but this has not been my strength in the past. I know random things – more like trivia – I’d do well at programmer jeopardy. But a seeker – they know the intimate minutia of edge cases. You won’t be able to prove them wrong. Not on a specific detail. This a huge strength. They know things – and if they don’t know it, they figure it out. They are a valuable resource to others and often end up in SME type positions.
Another attribute that is a strength is their strong work ethic. I’ve not found a seeker that isn’t consistent in their work. They really emphasize their work – they are driven and often ambitious. They’ll often have side projects – and those side projects often dovetail with what they are working on professionally. These side projects can sometimes be a distraction as well. Especially in more junior level seekers.
Seekers are incredibly prone to getting lost in a code base. The larger the code base, the more likely to get lost. The term can’t see the forest through the trees is the most relevant. Sometimes, seeing the forest is needed to solve the problem.
Making a mistake is a huge detriment to seekers. They aren’t able to easily brush off failure. One incident I remember in particular, was a bug that made it to production. It was a benign bug – a misunderstanding in requirements. But it really bothered the developer. They had recently started a new project, but wanted to drop everything to understand the bug they’d written. They even went so far as to work on the bug in the free personal time. Unfortunately, it undercut there progress on the new project.
Being correct to a fault. I’ve argued with seekers on a few occasions. Not because they were wrong, but because their focus was off. They knew exactly what they were talking about. They knew their context. But they had a really hard time adjusting their viewpoint, because they knew they were right. The blind adherence to their understanding is possibly the biggest weakness early in a seeker’s career.
Sometimes, what they know causes them to be judgmental. Knowing the proper way to do a thing can make it hard to accept a shortcut – or a workaround. This in particular can cause delays – or even destructive implementations of work-arounds. I’ve seen this on a number of occasions. It feels like sabotage when you’re managing a developer that does this. For a seeker – implementing the work-around is completely against their nature. Getting their buy-in, their agreement, is difficult and crucial in this scenario. And don’t be surprised if they point to the work-around as the source of problems anytime in the future. Especially in meetings with others. They’ll crusade to ‘fix’ the work-around whenever they have a chance.
Areas for Growth
Find the forest. Understand that there are often larger things afoot then a single developer can handle. Larger often then a single manager can handle. Understand there is a forest – and sometimes, trees grow crooked to reach the light. Growing a perfect tree is great for a back-yard. But growing a perfect tree in an imperfect forest isn’t always possible. That is to say – larger projects aren’t always as clean cut as pet projects. Expect great code – but don’t get too bent out of shape when great code isn’t perfect.
Understand that perfect is the enemy of good. Strive for perfection, but understand what is good. Know when something is ready to be shipped and supported – instead of focusing on winning Nobel peace prize for the perfect for loop execution.
Guide others through knowledge sharing. Don’t bludgeon other developers into your way of thinking. You’ll alienate them – and they’ll remove your code the first chance they get – because they didn’t understand, and, they didn’t get along. Teach others about some of the intricacies. But remember – sometimes, those details don’t matter. Know when to back-off, when to listen, and when to let go.
Do you think you’re a seeker – or is there one you know? Maybe you have a different idea for a seeker? Please comment and let me know!