Always Answer the Phone, Respond to the Email, and Go to the Interview

Several years ago I worked with someone who really felt he was happy at his job. Was he? I don’t know. He never mentioned not liking where we worked, but at the same time he never gave himself the opportunity to find something new. Each time a recruiter called about new employment opportunities, he blew them off and actively convinced them to not call again. Is this a problem? Outside of possibly being impolite, no, but it is limiting. By never inquiring about other opportunities, he never knew what he missed.

On my team, we have a rule: Always answer the phone, respond to the email, and go to the interview. It’s simple, if someone calls regarding a job opportunity, you must at least listen to their proposal. Upon hearing this, people surmise it is to remove under performers, or people who don’t mesh with the team. This isn’t the case. There are many reasons we have this rule, but they distill to two important goals.

  1. It forces the team to acknowledge anyone could leave at any time. Admittedly, this is self serving. Having one person with all the knowledge on a particular subject is an easy path towards failure. This scenario simply cannot exist in the long term.
  2. The more important reason is: We want our team members to succeed. Unfortunately, this doesn’t necessarily mean they should stay. Another position may allow them to grow with new responsibilities, it may allow them to learn new technologies, or it might be a better fit for them personally. By making it explicitly clear that we expect our team members to talk to recruiters and interview at other companies, everyone knows their best interests are placed above the necessities of the team. Everyone knows, this is just a job that might end tomorrow, and they also know your life is your life, and it might end tomorrow.

Even after explaining this, I get pushback. People tell me they are happy, they don’t want to take the effort interviewing, or risk what they have by changing jobs. I always respond to them with three points.

You don’t know what you don’t know

This is partially true for all industries, but it is especially pertinent for the tech industry. Things change all the time. Standards, applications, methodologies, approaches, and several other aspects constantly appear, influence, and fade. Your career is your career and no one else’s. Without constantly watching what is happening, you have no idea if your skills are relevant. The organization you work for does not have your best interests in mind. (Nor should it.) The people in charge can and must make decisions towards what is best for the organization, and it may not coincide with what’s best for you. Unless you actively take notice and explore other opportunities, you will never know where you stand in relation to everyone else.

You never know when you might need to change jobs in a hurry

My first job out of college, I worked at the same place for about 2 years when a friend called with shocking news, “Something is wrong. Your company has been delisted from the stock market.” Four hours later, everyone gathered in the cafeteria and management announced the company declared bankruptcy. Outside of a few people in accounting and the executive staff, no one knew there was a 50 million dollar debt payment due, and we couldn’t secure a line of credit to cover it. We were all dumfounded. We spent the last 6 months significantly reducing expenses and increasing income through new lines of business. There was nothing that could have prevented this, and outside of the executive staff, no one knew this was going to happen. One week later, over half the company was laid off while the rest stayed to handle the continuing business until they could sell the assets of the company.

Some people found jobs quickly, but others weren’t so lucky, because several of the development groups used waining technologies. Most of the staff never imagined this happening, and although they were decent at their jobs, companies didn’t want to spend time or money training new employees. It was unfortunate but true, and had the developers evaluated what they would need to find a new job, they might have had an easier time. What everyone learned was: Even if the job market is favorable to your occupation, it still takes time to make contacts, research potential opportunities, and move through the hiring process.

With this in mind would some of the people changed jobs earlier if they even remotely thought this was a possibility? I can say unequivocally, yes. There were several people that didn’t like working there at all, but they stayed, because they felt nothing was better than what they had. It’s much easier to be unhappy than it is to be confronted with the unknown.

Are you happy or are you comfortable

This is an important distinction. Most people confuse being comfortable with being happy. Happy is being able to say no to a better offer. Comfortable is being afraid that something better might come along forcing you to make a decision that might be unpleasant. Being comfortable is an illusion. It is a way of deceiving yourself so you don’t find another opportunity. Why is this true? It is true, because the fear of uncertainty is much more uncomfortable than the current unhappiness.

Jim Carrey during a commencement speech told a story about his dad and how he took a job that he didn’t want, because he thought it was the safe choice. The story ends with his dad losing his job, and Carrey said he learned many things from his dad, but especially, “You can fail at what you don’t want, so you might as well take a chance on doing what you love.” The perfect job comes along once in a great while, and it is different for everyone. If you don’t actively pursue it, you’ll never know it’s there.

I have never worked at an organization where my job was completely secure for an extended period of time. I have worked for large companies and small ones. I have worked for startups and established organizations. You may not know it, but no matter where you work, something is always in flux. Whether it’s a major client that is considering leaving, a lack of proper accounting or even embezzlement, there is always something that could cause your position to not be there in the morning.

Things you Should do with Strings While Your Coworkers are on Holiday and No One is Checking the Production Code Branch

Hi everyone! This is part of the really cool new CS Advent Calendar run by Matthew Groves! Go check out all the really great articles by everyone!

In a non infrequent basis, interviewers ask the question, “What is a string?” and they are looking for a quick answer similar to, “It is an immutable reference type.” This normally, sparks follow up questions such as, “explain what immutable means in this scenario,” or “so are there any examples where you can change a string?” The most common answers is, “No,” and with good reason. Adding two Strings together creates a new third String. Calling methods like ToUpper() doesn’t modify the one being operated on. It creates a new string, and although strings can be treated like an array of characters, the compiler prevents the modification of those characters in their specific positions.

Technically, the more correct answer is, “It depends.” Under most circumstances, it is not possible by design, and rightfully so. There are several factors dealing with efficiency and predictability that rely on this fundamental idea, but this doesn’t encompass the “allow unsafe code” compiler option. This is in a sense cheating, as it goes against established ideas of how most .NET applications work, but with this, it is possible to mutate a string using the fixed statement, and exploring it exposes some interesting behaviors of the .NET runtime.

To elucidate this, I created an assembly project and a unit test project to show various scenarios using the fixed statement and what happens. In these examples, the unit tests don’t actually test for validity. They merely bootstrap the test methods and print the results.

So what is happening with this code? The first necessity is to understand what the fixed statement does. According to the C# Language Reference:

The fixed statement sets a pointer to a managed variable and “pins” that variable during the execution of the statement. Without fixed, pointers to movable managed variables would be of little use since garbage collection could relocate the variables unpredictably. The C# compiler only lets you assign a pointer to a managed variable in a fixed statement.

With the fixed statement, it is possible to change a string in place which breaks its concept of immutability. The unit test:

  • prints the public readonly string “Bah Humbug!!!!!”
  • runs the method which alters that string
  • prints the same string which is now “Happy Holidays!”
  • show output of unit test.

    Now what happens when a local string is modified that is the exact same as the class level string?

    At first glance, the local string (localSeasonsGreetings) should be modified, and the class level string (SeasonsGreetings) should be unchanged.

    In this example, the unit test runs the method which prints out the values of the local string and the class level string, and then the unit test prints out the value of the class level string.

    copy of string results

    The local string is modified, and the class level string is also changed. Why did this happen? The answer lies in String Interning. When a literal string becomes accessible by the program, it is checked against the intern pool (a table which houses a unique instance of each literal string or ones that have been programmatically added). If the literal already exists within that table, a reference to the string in the table is returned instead of creating a new instance. Since the two string entries in the example are the same (Bah Humbug!!!!!), the runtime actually creates one reference for both of them, and hence, when one is modified, the other is affected.

    So what happens if we piece together the string at runtime from two constants?

    Notice in the example code above, the localSeasonsGreetings literal is changed to:

    mutate pieced together copy of string.  Shows different results.

    Since the local variable instance of Bah Humbug!!!!! was created when the method was run (and is not a literal), the CLR created a new instance of this string. When this local instance was modified, the class level variable instance was not differing from the previous example.

    What happens when the same string value is in different assemblies?

    Mutate local copy of bah humbug value in test assembly.  Is modified.

    Based on the previous examples, it works how you would expect it to. Since String Interning is controlled by the CLR and not during compile time, which assembly the string is located in doesn’t matter. All literals loaded into memory are added to the same pool, so modifying the value in one assembly affects all other instances in the entire application.

    Up until this point, we’ve only seen the effects of String Interning on instances of a string. What happens if we return a literal from a static method? To test this, I added a method to return “Bah Humbug!!!!!” to the ImmutableStringsExample.

    static method single call - no change

    The static method was called after the modification method ran, and it did not change. We could assume that since the method creates a new string instance, and the static method after we modified the interned “Bah Humbug!!!!!” string reference that it couldn’t find it and created a new instance. Now the question is, “Is this method deterministic?” Will this method always return a new instance of “Bah Humbug!!!!!!”?

    call static method twice change

    Clearly the answer is no. The time when the application calls the static method, determines its behavior. Now what happens with a non-static method? Are the same methods in different objects the same?

    Second instantiated object - different

    Non static methods work the same as static ones in this regard. Once ran, the CLR will make updates and return a reference to the same object.

    With the above examples, we see that Strings in .NET are really a lot more complicated than they initially let on. The runtime handles a lot of complicated optimizations, and there is a lot of work that goes on behind the scenes to ensure that efficiency. With those efficiencies come certain restrictions, such as immutability, but in the whole scope, those small restrictions can be managed and used to benefit the application.

    The code for this post can be found on GitHub