Dev Profile: Seeker

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!

Dev Profile: Speed Demon

Miriam-Webster defines a Speed Demon as someone that moves or works very fast. Some people just have this need for speed. Software developers at not immune. There aren’t many speed demons out there. Turns out, a lot of risk takers don’t like the idea of sitting behind a desk pecking away at a keyboard. But for those that do exist, here are some more common traits, and some things to look out for.


Has Fast task completion

Give a speed demon a well defined ticket, and the turn around time will be significantly less then their counterparts. For some reason – racing through tickets to the solution is was they feel gives them the edge.

Missing attention to detail

However, watch out for simple mistakes. It’s not laziness – it’s just slow proofreading code over and over again. That’s what tests are for. That’s what code reviews are for. It’s great that they can do things quickly – but a little bit of slowdown, and fewer issues is a much stronger result.

Has a strong grasp of the whole code base

The speed demon truly tries to grock the entire code base. It’s the only way they can move quickly. Given a task, they’ll study it upfront, make assumptions, try some things, then come back with a working – although not always optimal solution. It will work though. Mostly.

Missing blindspots

A speed demon’s true weakness is blindspots. If they miss something, and moving fast they are going to, they truly miss it. The earlier in the process it is, the bigger the mistake. Usually it’s a problem understanding, or missing, requirements. Sometimes it’s just forgetting to dot the i’s and cross the t’s.

Has a tendancy to showoff and brag

Most of the time it is a good thing for a developer to humbly celebrate their victories. Some speed demons aren’t humble – they try to offset their speed with victories. They won’t mention the mistakes, although they often reflect heavily upon them.

Missing compassion when others are slow

From a soft skills perspective – other people being slow is annoying. And expressing that isn’t a good soft skill – it’s more a lack thereof. Understanding what a slower more consistent develop brings to the table is a huge boon to the speed demon.

How to get ahead as a speed demon?

Try slowing down a little and making less mistakes. Try to lift up the team, instead of pushing / pulling them in the direction you want to go. Beware of scrum – because the points are based on the team’s velocity – you won’t fit well with the smallish tickets created on a scrum team. That said, you can use it to your advantage and plow through more points then others on the team. If your manager is attentive – and you aren’t making a lot of mistakes that everyone else has to clean up – you’ll do quite well in scrum.

How to work with a speed demon?

Mass migrations, large refactors – these are their bread and butter. Everyone else might think they are tedious, but for someone trying to fly through something quickly – these work well for them. Make sure they have the project in hand, maybe have them test the base case, then move on to the remainder of the task. Don’t make the same code review expectations on a project like this. In fact – make sure the base case is solid – if it isn’t, don’t let them continue until they can make a migration successfully.

Try to keep them from overrunning projects with unique properties. In their zeal for accomplishment they might miss the larger picture, and possibly block up the entire team with their CR’s that aren’t quite what was needed – but are super close.

Think you are a speed demon, or know one? I’d be curious to know! Feel free to leave a comment. If you like what you read, please share it! – and, as always – thank-you for reading!

Dev Profile: Maintenance Master


If you’ve ever worked in a service industry, you’ll have noticed that there are many people that just do their job. They go to work, do what they are supposed to, collect their paycheck, and punch out at the end of the day. They fill a role, and they do well at it. They stay out of the spotlight – their ‘off’ time being their fulfilment, and the job being an ends to a means. The same holds true in the Software Development environment.

Software stacks are large these days. Well, at some startups the code base is still growing, but even their, the open source code being referenced is quite large. Now, it’s great when a developer / architect can build and design these larger complicated systems. But as time goes on – new things don’t need to be built out so much as in the past. Sure, things like GDPR can wreak havoc on websites, but for the most part, code bases are pretty stable.

Ideal Scenario

An example of where a Maintenance Master is most suitable: Imagine a stable codebase which doesn’t need to be completely re-written. It needs to be maintained. Minor to Major bugfixes, improvements, business logic changes – these are common maintenance items. This type of work can be well planned out, well tested, and scheduled. Which makes it the ideal scenario for Maintenance Masters.


Being able to keep a code base alive and relevant is no small task. Knowing the reason for business logic implementations. Having a history of decisions. Doing all this without checking the Repository history or checking the resolved tickets list is a huge asset. In addition to this, they are great at sticking on a problem until it is eventually resolved. They’ll guard their area of expertise and are predictable about the deadlines they can meet. Sometimes they’ll explore new ideas or concepts – but they are largely happy with the status quo. They are able to churn out a lot of code – but it’s going to be the same code style repeated in every scenario.

To summarize:

  • Consistent
  • Dependable
  • Thorough
  • Content
  • Knowledge Stores
  • Persistent
  • Produce a lot of code


Being able to stay on a single project or code area for a long amount of time might be great – but it is countered by being unable to see larger solutions or newer approaches that can clean up the code. For example – the DevOps movement has put a huge dent in the abilities of maintainers. Now, their entire process must be revamped. This in turn causes maintainers to become disenchanted with their code or their company – and often will result in their departure for a more stable opportunity.

Not being a part of the huge ‘go getter’ mindset, maintainers don’t typically go way above and beyond the job description. They aren’t typically looking for a promotion and often watch others pass them by. They’ll sometimes get stuck maintaining a failed piece of code without realizing a refactor would be more useful in the long run.

They also sometime lack in their communication skills. They know their job – they expect you know yours, and they don’t anticipate communicating what they are doing outside of what the process makes them communicate.

Managing a Maintainer

There are some obvious do’s and don’t’s when managing or leading a maintainer.


  1. Keep their work planned and organized
  2. Give them an area to own
  3. Give them some autonomy
  4. Keep their environment stable
  5. Provide early notice for large changes conceived for their area
  6. Use them to train new people


  1. Haptic switching of their projects
  2. Expect new ideas
  3. Promote them to architect positions
  4. Use them to interview
  5. Push them outside of their comfort zone.


Maintenance Masters are an excellent piece of a development team. They will keep the lights on and things stable. They won’t push much of a changing agenda – but they will get things done. If you blame a code base, you’ll find their name dispersed through a file – not as an originator, but as an editor. There is absolutely nothing wrong with being a maintainer – however – if you are one, and you want to move into management or leadership, you’ll need to step out of your comfort zone.

Dev Profile: Emergency Response Hero

Someone just noticed Production fell over. Ops is looking into the situation. Devs are looking into the situation. Dev Managers are hovering – the situation is tense. In terms of the Restaraunt Analogy – Someone sent the wrong dish to a customer, and the kitchen is trying to recover. Enter the Emergency Response Hero (EMH)! With one look at the problem – he asks a few questions – fly’s through recent commits, check configs, and quickly ascertains where the problem is. Without telling anyone – he jumps towards the fix – and lets everyone know, “Hey, I’ve got it. Here’s the problem. Here’s a fix!” The fix goes out and all is well with the world. Until the next emergency. Everyone lauds the hero with accolades! …and the person responsible for the initial issue hangs their head in shame.

In the real world – as opposed to the world inside a development shop – Emergency response heros save lives every day. Natural disasters and accidents are common. We live in a chaotic universe. We need and appreciate our Emergency personnel for good reason. But what about a controlled environment? It’s a great thing to have someone capable to recover quickly from an issue at hand. However, there comes a point where relying on emergency personnel all the time is a problem.

Do you have someone in your team that wear’s a fireman’s hat (or equivalent) to work?
Do you have someone unable to complete and planned work as they are always saving the day?
Do you know a dev that gets more accolades then anyone else – but not for innovation but rather fixing things?
If you answered yes to any of these, you might be working with an EMH.

Working with an EMH can be rewarding for a dev manager. But, at the same time, they can demoralize the crew. Some will respect his accomplishments. Others will be ambivalent – and others, hard workers that don’t get accolades, will be jealous. When people become jealous, they become demoralized. Then productivity falters. But how to avoid this? Personally, I recommend better Automated Testing. A highly visible EMH is a strong indicator that Automation is not doing its job. Try to get ahead of this curve before it is too late. EMH’s get burned out too.