Over Christmas a family member (you know the type - ignorant older generation, who doesn’t know “what you do”) took target practice at my career.

People like this are usually easy to manage, but it did make me think about protecting your own brand.

I use the word brand quite deliberately. This is what I do, this is my career, this is the hobby I made into my career.

It is up to me (you) to manage the expectations of work, and personal life.

De-skill at your own risk. Learning new things is great, but stay focussed on the core (defining) parts of your brand (career).


Make sure that you spend enough time with your children, and significant other.

  • Make a point of telling your family that this thing you do is important. I will leave it up to you, how important.

You need to learn, practice, and fine tune your skills.

  • Make sure that you have a place where you don’t get interrupted. You need a space to think, to design, code, debug, build, and create.

But if you can code, and play with the kids - that’s just fine :O)


  1. Don’t let a business marginalise developers.

    It’s easy for a business person to look at developers, and label you as a developer (just go and code in the corner).

    Don’t let them. Be commercially aware, available, throw ideas into the ring when asked, don’t just communicate problems, suggest potential solutions.

    But when it’s time to “think, design, code, debug, build, create” make it clear that this is the technical bit.

    It you were a scientist, with a white coat, and lab, or a musician going on stage - you would be given this space, without asking. Why do developers have to justify what they do….?

  2. Constantly improve, refactor, and resolve.

    If your build and deployment process is too manual - identify the easy-to-automate bits, and automate the hell out of it.

    Please don’t say “this is not my job - I am a Java developer”.

    Wonderful if you have a devOps person to do all this for you - but better (and more realistic / real-life) to include these tasks in your backlog.

  3. But, be careful - don’t make yourself too available.

    If you are picking up the crap jobs in a team, do something about it.

    For example, if you have to do manual jobs which a baboon can do, -> automate the hell out of it.

    But don’t let another developer get away with the “i’m not interested in this, I just want to code” argument. All team members should know how to do the good and bad “bits of work”.

  4. Manage the agile practitioners

    Agile is fine - but don’t be told how to “think, design, code, debug, build, create”.

    Make it clear that this is the technical bit.

    There is nothing wrong with discussing improvements, but don’t let agile practitioners simplify what developers do, for example try to standardise a piece of work, which cannot (currently) be (standardised).

    You are not screwing car doors on a production line - you are better than that.

  5. Full stack developer

    All encompassing jobs descriptions - be wary of these. If you are not careful, you will be screwing car doors on, instead of the important / interesting parts of your career.

It’s your career. Don’t expect anyone else to look after it for you.