Consent Disclaimer

You may hear Group Member’s from Pulse Group talk about “defining your brand”, but what does that mean? A person’s individual brand is something different for everyone. What it came down to for me was my reputation. For example, are clients I work with concerned about how the program is going to work, how long it is going to take, or am I going to push the deadline off? I recognized, if I have a reliable brand (or reputation), these questions or concerns will not have to be asked by repeat clients, as they will already know the answer when they learn who is programming the job.

Defining your brand is not just about programming – it can also be about how you handle yourself in front of clients – do you give off a professional aura? Anyone you employ or who represents your company who has a bad attitude or poorly defined brand can damage a company image and eventually lead to client’s not sending work your way.

Back on track now for programming, at some point there will come a time when you feel ashamed at the situation and decide there needs to be a change. For me this was when I was done with a job, had made no programming changes in quite some time, and so to me the job was complete. I would hand off the iPad to a Group Member to play with and within 3 minutes they would find a bug. If I had I tested the iPad fully, I would have found the bug and avoided looking unprofessional or careless.

As a programmer we get into this mindset of “I programmed that so I know it works and I don’t need to test it”, or the classic case of “I tested one function of a group, and that works, so I don’t need to test the rest of the group”. I have learned the hard way with both of those cases and they are absolutely not true. My conclusion: test, test, and test some more. Do your own testing. You may not think much about it but your clients will notice it, other programmers out there pawn testing off to their clients and rely on bug reports, at which point you are at the mercy of the technical ability of your tester you will get anything within the range of “It doesn’t work” to “Do this, this and this”, and “That should happen but it doesn’t.” This all boils down to doing your own testing, even if the client insists on testing, wait and let them test a fully functional system. That will only do wonders for your brand.

By now you probably have a good idea of what your brand should be even if you don’t think you can do the whole thing at once. I suggest starting with something small. For example, make sure your cable boxes work all the time, one hundred percent of the time; or even better a TV that turns on every time! So many times I’ve fixed code on a jobsite for an upgrade where the TV was not turning on or off every time. Imagine what the client experiences!

Defining your brand will help you grow as a programmer. It does not matter if you do this full-time or part-time; take a step back, think about all your job and answer a few questions about them:

How did the job go?What were the problems with the code (not problems introduced by home owner/install)?How can I fix those code problems so they do not happen again?Did anyone say something about user interface design – good/bad?Are you proud of that system and to have your name attached to it?Did I test the system entirely?Create a unique experience for your clients that can only be replicated by using you. As a programmer, you want that job to come and go, and only want to hear about that job when there are upgrades – not that there are problems. I get that. But challenging yourself to define your brand will only help you grow and reduce potential complaints or bugs in the system.

Defining your brand is not all about the client experience either – it is also about how you feel! Your client could say nothing to you, but as long as you can answer the questions above with confidence, you will end each job feeling valuable and proud. That is priceless.  What it came down to for me was my reputation. For example, are clients I work with concerned about how the program is going to work, how long it is going to take, or am I going to push the deadline off? I recognized, if I have a reliable brand (or reputation), these questions or concerns will not have to be asked by repeat clients, as they will already know the answer when they learn who is programming the job.

Defining your brand is not just about programming – it can also be about how you handle yourself in front of clients – do you give off a professional aura? Anyone you employ or who represents your company who has a bad attitude or poorly defined brand can damage a company image and eventually lead to client’s not sending work your way.

Back on track now for programming, at some point there will come a time when you feel ashamed at the situation and decide there needs to be a change. For me this was when I was done with a job, had made no programming changes in quite some time, and so to me the job was complete. I would hand off the iPad to a Group Member to play with and within 3 minutes they would find a bug. If I had I tested the iPad fully, I would have found the bug and avoided looking unprofessional or careless.

As a programmer we get into this mindset of “I programmed that so I know it works and I don’t need to test it”, or the classic case of “I tested one function of a group, and that works, so I don’t need to test the rest of the group”. I have learned the hard way with both of those cases and they are absolutely not true. My conclusion: test, test, and test some more. Do your own testing. You may not think much about it but your clients will notice it, other programmers out there pawn testing off to their clients and rely on bug reports, at which point you are at the mercy of the technical ability of your tester you will get anything within the range of “It doesn’t work” to “Do this, this and this”, and “That should happen but it doesn’t.” This all boils down to doing your own testing, even if the client insists on testing, wait and let them test a fully functional system. That will only do wonders for your brand.

By now you probably have a good idea of what your brand should be even if you don’t think you can do the whole thing at once. I suggest starting with something small. For example, make sure your cable boxes work all the time, one hundred percent of the time; or even better a TV that turns on every time! So many times I’ve fixed code on a jobsite for an upgrade where the TV was not turning on or off every time. Imagine what the client experiences!

Defining your brand will help you grow as a programmer. It does not matter if you do this full-time or part-time; take a step back, think about all your job and answer a few questions about them:

• How did the job go?
• What were the problems with the code (not problems introduced by home owner/install)?
• How can I fix those code problems so they do not happen again?
• Did anyone say something about user interface design – good/bad?
• Are you proud of that system and to have your name attached to it?
• Did I test the system entirely?

Create a unique experience for your clients that can only be replicated by using you. As a programmer, you want that job to come and go, and only want to hear about that job when there are upgrades – not that there are problems. I get that. But challenging yourself to define your brand will only help you grow and reduce potential complaints or bugs in the system.

Defining your brand is not all about the client experience either – it is also about how you feel! Your client could say nothing to you, but as long as you can answer the questions above with confidence, you will end each job feeling valuable and proud. That is priceless.