Developers, by nature, are very logical. Due to this, a few of us struggle with some of the more "intricate" details of our career, interactions, and elements of our role / responsibilities that are less "code-y".

Over my years, ranging from a Data Manager, IT Support Technician, Developer and a IT & Development Manager - I've learned a few little handy tricks that help me out. Hopefully some of these can help you out.

Starting out

I get at least 3 people a week contact me asking; "How do I get into web development? Where can I learn to do what you do".

And to those people, I always say the same thing, build something. Anything. It can be the worst program / website in the world. Just build it.

My first "project" that I ever built in PHP, was a currency convertor. It took a users input, and sent it to the fixer.io API. It then dumped, yes DUMPED, the response on screen for the user to somehow figure out. It was messy, hacky, accepted raw $_POST parameters, and had NO validation. But it was something.

If you're worried about breaking stuff, or somebody seeing your code, don't worry. GitHub now has unlimited free private repositories for everyone. You can also use boxes such as Homestead, or The Scotch Box so that all your work stays local.

Saying "No"

This is IT. We can do "anything". Due to this, there's a lot of "Yes Man" attitude in the industry. Personally, I despise this. There's many ways of telling a client, or your senior, that something either cannot, or will not happen - without explicitly saying the word "No".

1. "These changes will need reviewing, and your scope adjusting. This will impact project delivery, and budget."
1. Client will generally review the change as unnecessary, out of budget, or allow you more time!
2. "If these changes are required urgently, then [Project X] will have to be delayed - is that an acceptable change of priority for you?"
1. Project X will either get moved, or the new changes / project will be pushed back
3. "The project / change, has a larger cascading impact on other areas that could have unforeseen issues. To accommodate this, we need to extend the project dates, and budget, to allow for more testing time(s)"
1. Clients, for the most part, hate paying for testing. This will either get you more time on the change/project, or the request pushed back to a later date

Project Estimations

Your MD, CTO, Scrum Master, office dog, whoever - it doesn't really matter - wants an estimation of when the latest project "Alpha" will be ready.

How do you estimate this?

In your head, you rattle through the minor changes that ultimately make the project / amendments. A day here, two more there, couple of hours for this, half-day on the other. You total up 10 days.

Tell your superior / client, **at least **1.5x that. Why? Am I just squeezing budget out of someone? Not at all - I'm protecting myself, and my work.

Here's a breakdown of why I'll always add at least 50% to any estimation;

Testing

Make time for tests. Don't tell your client you're doing it - make it part of your development flow. If you've got the time, and resource to do it, try Test Driven Development.

Scope change

"We wanted this, but now we want that". Happens all the time. You can say no, if you really want to. Some changes however can be beneficial as they make things easier - always weigh up your options

Scope creep

Ah, the dreaded creep. Something will get "thumbed in" - this button now does this, styling has slightly changed.

You can always go back, and refuse these changes. Just use one of my "Saying No" statements if you need to.

Feedback / Amendments

After your first round of development, things will need changing. You can add time for this early, so you know that you have space to do it. Or, list this as a new task, and bill accordingly - it's up to you.

Unforeseen integration issues

Fail to plan, plan to fail. Expect stuff to go wrong, and you're going to have to sort it. You're a human, you're going to make mistakes

Note: Naturally, if you deliver early, you have a decision to make. You can either notify the client, and refund / credit note them for the work. Or, you can do more tests. Always do the latter. It's far less hassle, and you can be more confident in what you're delivering.

Office Politics

Person X doesn't like Person Y. They want to know your opinion of them. Just stay out of it as best you can. Office politics is a deadly spiral, and the last thing you ever want to get involved in.

I've been taken into other people's disciplinary hearings before, to give a statement on a situation, simply because of politics. Not something I want to ever do again.

Getting involved in office politics is something that can easily see you out of a job. You can be the best person for a role - a perfect fit - but if you get involved in the wrong discussions, you'll soon be looking at job boards again.

The way that I stay out of office politics is very simple, choose every word you say, very precisely. In meetings, say the bare minimum required, and even then make sure you're very exact in what you say. To begin with, this will prove difficult. However, over time you'll become fluent in saying nothing.