Thursday, November 24, 2016

How to figure out if your job really sucks

An obsessive idea to change the job is more often caused by an emotional urge than the real need. Try to fix the situation first. Didn't work? Consider all aspects carefully before jumping to the action. Not just this simple exercise will enable you to make an informative decision but should you conclude that benefits of keeping the job outweigh benefits of leaving, it will help you to stay positive and be happy and productive (or embrace your new position with open arms otherwise).

A lot of people thorough analyze their investments but take change-the-job decision overly lightly, while the latter affects your present and future life at least on the same scale (if not bigger). So be methodical and write down pro's and con's for your job. And: money is always among the important considerations but not the most important one.

For example:

- What is bad about you work now:
1. I do the same stuff ever and ever again, I am bored.
2. I want to work with exciting new people.
3. I am underpaid.

- What is good:
1. I know exactly what I am doing, I understand the clockworks very well, people come to me with their questions and I am capable of providing a valuable help.
2. I am accustomed to the team, I understand all the do's and dont's when dealing with my colleagues.
3. My workday is not crammed as I can navigate between my tasks efficiently.

And now you can analyze your claims and weight them out. Can you really sacrifice the comfort of the "Good 1" and is the "Bad 1" really that bad? Most likely you won't get them both satisfied at once - they are balanced.
The money seems to be the trickiest question of all, but ask yourself - do you really familiar with the current market? Could it be that while you stayed at your job for last 2-5-10 years your expertise became less relevant? A lot of companies who put efforts in stuff retention, inadvertently create an over-confidence in their employees, praising their achievements and over-boosting their confidence. It is a good practice (and a "must have" feature of the good workplace) but aside of quite rare super-achievers a lot of well-performing employees are just normal regular Joes who happens to apply their very specific experience to the very specific job - and it is not the fact that it will be sufficient for the new workplace.

Wednesday, January 06, 2016

WebAPI: default formatting, better dates and KnockoutJS friendliness

The notorious problem with JavaScript dates reminds me the technical relationship between space shuttle and a horse: once upon a time IT was ruled by Unix people who liked incomprehensible dates (probably they were already programming towards the world domination - ICBM navigation, global stock trading and private jet scheduling).
Scott Hanselman dedicated a post to this problem back in March 2012 and sworn that natural JSON dates will be no more. David Warp seconded. The change seemed to make it in the release available as of August 2012 - awesome, but I wanted to keep playing with the nice formatters mentioned in the said posts. Unfortunately I couldn't even compile them and guessed that by the time I reached for the installer the code behind the package has progressed significantly. Figuring out which assemblies to NuGet into solution or which references to add is a bigger pain (and less fun) than building more code - after all, who would enjoy copying somebody's code instead of doing own research?
The idea was to change the default serialization behavior for null properties to prevent my KnockoutJS from failing. Secondly I wanted to try and change default formatting for HTTP GET implementation, such as when API is called from the browser (not that it is really important with the content negotiation). And third - change the date formats to something more predictable and culture neutral.
The first compilation kind of worked (and it seemed to work faster in the browser):

Note the Unit property in the second address: in XML property is serialized with "nil" attribute, while the JSON implementation is actually missing it altogether - which would blow up the KnockoutJS bindings.

© 2008-2013 Michael Goldobin. All rights reserved