loading...

How to wage cold war on your employer(s)

spirodonfl profile image Spiro Floropoulos ・5 min read

This is a follow-up article to “How to wage cold war on your developers” where I provided anecdotal experiences of things companies do that scare developers away. I’m re-using the term in this article but flipping it.

I will share some anecdotal experiences from my past where I’ve made mistakes that I hope no developer has to make. As I hope other companies can learn from my previous article I also hope other developers can learn from this.

Overpromising

We all know this one. Employer asks “How long do you think this will take?” and in the back of your mind you're thinking “Probably a month but… If I say that then the client will run away or they will think I'm a joke” so your mouth says “Two weeks”.

I've done this several times. It's not good. It really is a disservice to yourself and to your employer.

Think about what you're agreeing to. Essentially you are agreeing to work 80 hours a week for two weeks instead of normal working hours. If you have a family or friends or both (you lucky dawg) then this kills you.

It also almost always ends in project ruin which ends in bad reputation for you.

Of course it also means the client loses money and time. What's more, depending on what the project means to their business, they could be losing money down the road. In some cases, people lose jobs.

Why does that matter? It leads to…

Not caring enough

I've had this mentality before: “It's not my company so it's not my problem. I'll code this however I want. I'll use whatever time I need. I need to do my job the way I need to do it.”

Part of this is ego. Part of it is a lack of concern for others. Corporations have become a bit humanized. You can talk about Apple or Google as if they are one single human individual. That definitely has merits.

Companies are composed of people, however. Companies provide income to multiple families and, in some cases, to entire economies. Technology can be such a huge component to all of that. You might be asked to hold that key for them and provide them the support they need.

What if it was your company? How would you want to be treated? The golden rule, if you will, can sometimes be an important rule to ponder.

There are exceptions like anything else. But please give consideration to aspects not directly in front of you.

Not respecting time

Your own time, primarily, is the most valuable commodity you have.

If you're programming to punch in, punch out and grab a paycheck, skip this. Skip this whole article.

If you care and are passionate then I urge you to consider the time you spend at this job. There's nothing wrong with pushing yourself, meeting deadlines, working hard in general.

I have a family and that includes a new baby, our first, and I recognize how little time I have to spend with them in general, let alone around working so much.

Don't neglect yourself, your family or your friends. Your own sanity and happiness is crucial to your success at work and you may not see that correlation until it's too late.

Also, respect your employers time. I've already touched on this briefly but do remember that your employers are paying you for work, not cat videos. Breaks are your right. But respecting their time is also respecting yours. If you were to track, in one week, every hour you spend doing work versus every hour you're supposed to be working, you might be surprised.

As a freelancer, this actually matters more to you for obvious reasons. Your productivity is pretty important when you're working on gigs. Keep that in mind.

Not respecting requirements

Again, ego might come into play here. I have sometimes argued against meeting certain requirements not necessarily because the requirements were bad but because I didn't agree with the approach required to get there.

Companies and clients will usually put a lot of thought into business requirements. It means something to them. It's not often for fun or just to try something or to burn money.

Give yourself a third or fourth review over requirements you don't agree with and ask yourself why you don't agree with them. If you have a solid case against it then your arguments will be clear (usually) to the employer and they will agree with you.

Overengineering

I almost don't have to write anything here. We all know about this one. You take fizzbuzz and add four micro services to it.

KISS

Look it up. Honestly, this saves time for you too. The passion to engineer correctly and flex those muscles isn't a bad thing. But you don't have to do it everywhere and on everything.

Skirting the mundane

Ugh I have to pull out all these queries from the codebase and move them over here and wrap them in a function? That's boring. A junior could do that.

I've thought that before. Insert a similar gripe here if you've ever had something boring to do that you didn't want to do.

When you're an intermediate or senior, it's easy to say “I've put my monkey time in already”.

Maybe that's true.

I will say this. There are plenty of occasions where I did not want to do something simple. I did it and ended up discovering problems and issues that I never would have found otherwise. Or that boring knowledge came in handy later when something else popped up and I knew exactly where to go.

Don't underestimate boring.

Carrying a large ego

I'm really not gonna write much about this because it's obvious.

I have worked with developers who have literally told me (while I was a junior) that they can't be bothered to give me the time of day over trivial matters. I had one literally say “I'm too important for this” and take off.

Check yourself. You are not Gods gift to the programming world. You are not Steve Jobs or Wozniak or whomever you value as a tech Guru superhero. You're you and you have to work with others. That includes clients who may be demanding and expect things of you that you might feel “above”.

I've had to learn that too. It can be overcome.

Conclusion

There seems to be a general theme here of respect yourself and others and don't carry an ego.

That's easy to say but, in the moment, when you're looking at a technical issue with a junior developer over your shoulder or a diva of a client, it's easy to forget.

I also recommend you spend some time on friends and family if you don't already. Even friends among fellow developers would be better than nothing. Seriously. Your mental state improves with social interactivity at even the smallest level. Reach out to me if you'd like.

If you want to know how to maintain peace, then read my next article here

Discussion

markdown guide
 

Oh boy did you hit the nail on the head.

The "I'm too good for this" person has only 2 solutions... and they both involve a door. Either find the door and leave through it, or kick that person through it.

"I'm too good for this" also means:

  • I'm not responsible for any design flaws
  • I'm not responsible for any bugs
  • I'm not responsible for any performance problems
  • I'm not responsible, it's someone else's fault.
  • I'm not a team player, and nobody means as much to this company as I do.

Anyone that thinks that their ego is sooo important, needs a lesson in humility, before they cost multiple people their livelyhood by causing a company to fail. Badly.

Always remember the first rule of coding: You are not your code. Just because the code may be good today, doesn't mean tomorrow won't contain a "steamer" that may or may not be caught. Everyone has a had on the bucket of work being done, as soon as you think you're alone... you will be.