7 habits of highly ineffective developers

By on April 18, 2017 7:07 am

While the SitePen team is widely known for its expertise in building JavaScript and TypeScript applications, providing support and training to enterprise teams, and for helping create Dojo and Intern, it also has a fair amount of insight and expertise with helping teams be more effective. Whether it’s Milestone Mayhem or InnerSource or just knowing how to keep software projects running smoothly, we’re often called upon to help organisations be more productive in modernising their approach to building applications.

Recently, we explored some of the habits that can sap the effectiveness of a developer. Even the best of us can get bogged down by challenges that make us struggle for too long. We believe that developers who better understand themselves and can identify these challenges before the bandwidth drain are more likely to be happy, satisfied, and productive. Do you recognise any of these bad habits?

1. FOMO (Fear of missing out)

This issue is defined as a fear of regret, which may lead to a compulsive concern that one might miss an opportunity for social interaction, a novel experience, profitable investment or other satisfying event. One solution to this challenge is to be aware of the opportunity cost. Just as much as context switching can be a major drain on productivity, anxiety over am I using the best tool for the solution can detract from actually making progress. Code is about change and refactoring and it is inevitable and natural for it to happen in most projects.

2. Ergo A blog legere…

This is Latin for “I read a blog, therefore…”

We often hear things like:

“Lots of people are using…”

“Exciting news! ________ is now one of the top ten most-starred projects on all of GitHub.”

“Hooli built…”

If we choose music like we sometimes choose technology, we would all be listening to Justin Bieber. The cow paths aren’t justification enough to use a technology or adopt a pattern.

A solution that works for us is to step back and ask a few questions:

  • What problem am I trying to solve?
  • What is the longterm cost of adopting something new?
  • Is this just a solution looking for a problem?

3. Because management says…

The challenge with blindly saying and following this is that it absolves responsibility because someone made you do something with which you don’t agree. This particular habit is common, especially in enterprise development. Good management teams don’t expect us to be sheep. They expect us to speak up to promote the betterment of the code, application and/or product.

There are, however, right ways and wrong ways to land this message. It’s important to remember that most people do not wake up in the morning and think I want to do a poor job today.

If you want to challenge something you think is wrong, consider the following:

  • Question assertions and belief systems in a non-confrontational way. “Oh, why can’t we do that? Who made that decision? May I talk to them?”
  • Try to see it from another perspective. Why might this be the case? Often it is good intentions gone awry which cause bad decisions to be made.
  • Be prepared to be challenged by superiors. From personal experience, I’ve often been challenged as a manager and I also challenge others to see if they’ve actually thought through their proposed solution. Sometimes things are nothing more than paper tigers and being challenged is a way to see if an idea is actually going to hold water.
  • Of course, if a manager is dismissive of a well thought out and reasoned idea, you might be in the wrong place.

4. Fallacy of Composition

The fallacy of composition is often defined as:

This arises when one infers that something is true of the whole from the fact that it is true of some part of the whole (or even of every proper part).

In practice, it’s everyone thinking I am going to stand up at the concert to get a better view and we all end up back where we started, unable to see the performance.

There is never a one-sized fits all solution to a problem. Individual actions have larger consequences, take the time to think about that and recognise that self-interest may not have the best long term outcome.

5. The Expert Beginner

This is someone who makes a career out of always being semi-competent and never mastering anything.

I had been introduced to the Dreyfus Model of Skill Acquisition via the great book Refactor Your Wetware by Andy Hunt. Then I read a blog post where Erik Dietrich postulated that there is this offshoot of the Dreyfus model where developers get stuck: The Expert Beginner.



To solve this potential ceiling of productivity, you need to recognise in yourself where you are on the scale and if you have become an Expert Beginner, and change immediately before you do more harm than good! When working in teams, recognise the skill level of others and when managing, make sure you try to meet the needs of people at the right levels to get the most out of them.

6. Un-self aware

One of the biggest challenges is that sometimes we are unaware of the carnage we leave in our wake. Some of us are acutely self-aware, but how do we know if we can up our self-awareness game? There are five common signs of not being self-aware:

  • Constantly Defensive
  • Must Micromanage
  • Make Excuses
  • You have been called a bully more than once
  • You’re in denial

If any of the above apply to you, you might want to consider improving your self-awareness. One common approach to increasing our self-awareness is to take a personality test to understand your tendencies, as well as how you relate to other personality types. Try to use a model whereby you can understand yourself, but also understand other people. When there is conflict or stress, at least recognising where that might be coming from is a big factor in changing things.

7. Actively disengaged

When someone is not only unhappy, but actively disengaged, this can create a vicious halo of melancholy that affects others and may lead to the undermining of others’ efforts as well.

If you ever find yourself in this scenario, you owe it to yourself and your colleagues to determine the cause. If it’s the current job or workplace and there’s nothing you can do to improve things, then you should do something else. If you see this in a colleague, you should take them aside and in a kind and caring way, let them know you have spotted them. Sometimes, people need that external wakeup call in order to re-engage, or to admit they need a change of scenery.

Changing our behavior

These seven habits are often easy to recognise in others, but I suspect that most of us would have difficulty recognising them in ourselves. Seeing them written out can help you exercise a little self honesty and hopefully, we’ve given you some ideas on how you might start tackling the issues that will help you become an even more effective developer.


A cow path is the concept of adopting something because there is a clear path of people already doing so, without evaluating if that something has merit on its own.

A paper tiger is something that appears to be challenging but does not hold up under scrutiny.

Comments

  • Duke Vukadinovic

    In my opinion, the most ineffective software developers are those who are reluctant to learn and adapt to new ideas!

  • Robert Parham

    why? just because something is new it automatically is the best? see “cow paths” above..

  • Duke Vukadinovic

    You’ve got me wrong Robert. Flexibility and a willingness to embrace change will make any person a more valuable member of their organization and adapting to change frequently requires the effective use of all acquired skills. They can never stop learning if they want to maintain their value in the job marketplace, but I agree with you that evaluation of the above mentioned ideas goes without saying.

  • There’s obviously (well, hopefully it’s obvious) a balance between the two extremes of “I’m set in my ways and unwilling to consider anything new because I already know everything” and “I only use the newest things out there and anything older than my attention span cannot be useful”. :)

  • Robert Parham

    I fully agree, but this attitude that the newest stuff is always the best is simply faulty. Google and Facebook and the biggest sites in the world don’t even use es6 in prod. (They might use babel but that’s besides the point). lots of users are alienated by devs who just have to use the latest tech. but if youre writing for node thats another story.

  • Robert Parham

    couldn’t have said it better myself :)

  • Aurelien

    I didn’t write you said something mean neither that you are a bully. But you got it that way right? Can you tell why? If so, then you found what is perfectible in your first comment, because I just copied its structure.
    You latest response to Robert is way more interesting and constructive. I wish you have said it that way on first time ;)

  • bklau

    I like to point out #7 Actively disengaged has one of its root cause of being a “perfectionist” developer. Usually, a perfectionist gets annoyed too easily when other developers don’t do it their way. Like a protective parent, perfectionists lashed out in meetings and code reviews. IMO, as long as the code is readable and maintainable and tested, who cares if its perfect because most degenerate after sometime, anyway. Upper management DO NOT care about code; only revenues it brings. Code is not a static piece of marble sculpture…

  • renzo

    Look, you’re programmers. You’re *all* terrible people, along manifold dimensions of terribleness.

    These blog posts are here purely as a cheap signal of expertise and “thought leadership” (eyeroll)—I don’t think we’re actually supposed to read these and take them seriously. Just nod and smile. Or troll and chortle, whatever. It’s just fodder for some bullshit mailing list that fundamentally functions as a lead generation vehicle.

    Anyone who willingly chooses to work with such social rejects (from the douchey brogrammer to the SJW-activist-coder to everything in between) has to either be fundamentally broken in some way or soon will be.

    Suck it, nerds.

  • Kitson P. Kelly

    Yes, going to any extreme is never good. Code will never be perfect. It is true that code is not a static piece of marble sculpture, just as you can’t take humans out of the code. Many people who excel at programming often struggle with human factors. If someone is a perfectionist, they need to take a step back from that and understand they aren’t an island unto themselves and they have to work with other people. For those of us having to work with a perfectionist, often having a direct conversation about what drives the perfection and engaging in a level of communication can help build empathy. Most root causes of human factors are rooted in a lack of empathy.