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.

Functional Languages in the Workplace

On a semi regular basis, people question why I choose to use F# to implement projects. They question why use a lesser known language when one like C# has a larger developer pool and is more widely documented. I explain to them my rational behind it, siting personal experience, and documented cases about others success stories as well. There is significant evidence showing functional languages can reduce commonly occurring defects due to their inherent nature of immutability provide easier support for scalability, and have a stronger type system allowing for more expressive code. There are numerous testimonials on the use of functional languages and their benefit, but after hearing all of this, they are still doubtful about even considering a change. Assuming this evidence is correct, the question of “Why isn’t this a serious choice for the majority of organizations?” continues to appear.
During discussions about switching to a functional language, I repeatedly hear the several common questions and arguments for resisting change. Most of these embody fear, uncertainty, and doubt. Several can be applied to moving to any technology, and although they should be considered, they are nothing which cannot be overcome. Here are my responses to the most common arguments against change I receive.

Our code is already written in language X, and it will be hard to make a change

There will always be legacy code, and it probably deviates from the standards used today. Was it written in a previous version of the currently used language? Does it contain libraries that are no longer supported? Was it written in such a way that converting it to current standards is difficult or impossible? If the answers these questions is yes, that doesn’t mean that other projects suffer the same fate.
Legacy code can’t hold you back from technological advancements, and it most likely doesn’t now. Over the last several years many software vendors have made sweeping changes to languages and technologies leaving them looking only vaguely like what they did when first created. The introduction of Generics, the inclusion of Lambda Expressions, and asynchronous additions made huge advancements in several different languages and greatly changed common approaches to solving problems. These enormous changes didn’t stop organizations from modernizing their many of their applications to take advantage of new features even though code written with them is radically different than in previously created applications.
Radical shifts in technology happen all the time, and almost every organization shifts its strategies based on trends in the industry. Organizations which defer changes to their current approach often find greater difficulty in migrating the longer they wait due to the fact that they continue to implement solutions using their current approach. Mindlessly shifting from one approach to another is never a wise decision. That introduces chaos, but neglecting trying new approaches due to legacy concerns can only end in repeating the same mistakes.

Our developers don’t know language Y. It will be too hard and costly for them to learn and migrate.

A developer’s job is to learn every day. There are new features to understand, new architecture patterns to master, and new languages to learn. The list is endless. The belief that at any stage in one’s career the road to deeper understanding ends, is myopic and ultimately an exit ramp to another profession or a stagnant career. Developer’s should be challenged. Organizations should push their staff to understand new things, and compared to the opportunity cost of repeating the same mistakes, the amount of time and money required to train people is often negligible, especially with tools like books, video learning, computer base training, etc.
There are some people that have no desire to continue learning, and that’s ok. New development isn’t for everyone, and going back to the previous point, there are always applications in need of support that won’t or can’t be converted. Organizational migration to a technology is almost never an all or nothing approach, and some solutions should be left exactly how they are, because of the cost of converting them will outweigh the benefits. There will be people to maintain those in the long term, and these solutions cannot be the bedrock against advancing how other projects progress.

What if we fail and we are stuck with a language we can’t use?

If an organization takes the leap of faith and switches to a functional language what is the probability of some failure during the process? The initial answer is, 100%. Everyone fails every day at something. Failure is inevitable. With this in mind, you’re already failing at something, so the question is what are you going to do to try and fix it? You’re going to create other problems too, but with planning, retrospective analysis, and learning from those mistakes, those will be solved as well, but ultimately the position you end at will be further along than where you started.
A few years ago, I had a discussion with an organization about their development practices. They were extremely adept at knowing where their time was allocated: support, feature enhancements, refactoring, etc. When asked about their breakdown, they explained on average 30% of their time went to fixing production defects from previous releases. They were perplexed about why they were missing deadlines despite becoming stringent on code quality. I asked about their plan to fix it, and they responded with a few ideas, but their final answer distilled to, “write better code.” When confronted with the question, “What are you going to change?” they said, “Nothing. Changing the development process is too time consuming and costly. If we update our practices, we’ll fall further behind on our releases.” The definition of insanity is doing the same thing and expecting a different result, yet several organizations believe they can break the cycle simply by standing still. If changing how an organization develops isn’t feasible, then changing what they develop with is one of the only few viable options remaining. It is much easier to change a technology than it is to change an ingrained culture, which is exactly why using languages and tools that enforce practices which reduce errors is a much more efficient approach than convincing everyone to work in a certain way.
Most organizations resistant to change perceive technology migrations as a revolutionary approach. They firmly believe all use of a certain technology immediately stops and the new one begins, because it is much easier to think in terms of black and white (one vs. the other) when change is a rare and uncomfortable occurrence. Change to anything new should be a cautious approach and take practice. It should be evolutionary. Organizations should try several smaller variations of an approach, learning from each and refining their ideas on gradually larger projects. Embracing a adaptation and “failure leads to a stronger recovery” approach ultimately leads to a better outcome.
It is almost certain moving from to a functional language from an unrelated paradigm is going to be difficult and confusing, but the fault does not lay to the language itself. As with anything new, the concepts are unfamiliar to those starting to use it. There will be mistakes during the learning process, and some projects will probably take longer than expected, but basing the long-term benefits on the first attempt to implement anything will show biased result against it, and with time moving to an approach which aids developers to make fewer mistakes and write better and cleaner code will save both time and money.

It’s not widely used enough for us to find people to support it

My coworker recently attended two meetups concerning functional programming, each having approximately 25 attendees. After the first one, he decided to do an experiment at the second. He asked people at the meetup, “How many of you use a functional language at work?” and the result was astounding. Only one person admitted to it, and it was only part time. At a minimum, there are 25 people at each location that are excited enough about functional programming to attend a meetup on their own time on a topic which has nothing to do with the tools they use at work, and these people are only a representation of the larger workforce. There are many others that were either unable to attend, or were unaware of the event.
There is almost no place in the United States that isn’t a competitive market for development staff. Large companies are able to pay higher rates and have better benefits which means they will pull the majority of the highest qualified candidates. Smaller organizations can’t offer the enormous benefits packages placing them in a difficult situation to fill needed positions. Picking a technology where there are fewer people to fill the role would seem to place those organizations at a disadvantage, but this is actuality in comparison to overall demand for those type of people. Looking solely at the number of potential applicants, the pool of functional programmers is smaller, but organizations using functional languages aren’t nearly as widespread, so they suffer less completion when searching for candidates. Furthermore, assuming the statistics surrounding the benefits of functional languages are correct, organizations will require fewer programmers accommodating the constraint of a smaller pool of applicants.

Conclusions

Functional languages can be an excellent fit for organizations, both ones starting development and others which have been established for a considerable length of time. Most resilience in using them comes from misunderstanding the benefits compared to the cost of changing languages. It is neither difficult nor time consuming to attempt to better the development process by focusing on tools to better aid the process.

Reclaiming Stored Procedure Code

One of the largest problems people have with keeping stored procedures in source control is not a disagreement that they should be but the change to the process in which they are accustomed to. Normally with code, you create a physical file which is then piped to the compiler to output an assembly. With Microsoft’s SQL Server Management (SSMS) Studio the process of creating a file and then running it has changed this, because the database stores the SQL code for procedures in the database negating the need for a physical file. This is a convenient shortcut but makes it difficult to keep SQL source in sync, because inevitably people forget to create the file from Management Studio when they’re done. SSMS has a menu item for generating a file, but the creation options are limiting depending on the need, and it adds additional code around the procedure which most of the time isn’t necessary. Not to mention generating one file is simple enough, but having to do it for hundreds of changed procedures is tedious and time consuming.

Script Procedure

Fortunately, there is a convenient fix for this. Since MSSQL Server stores the code in the database, you can easily retrieve the code and save it yourself. Microsoft created the INFORMATION_SCHEMA.ROUTINES view which returns information such as it’s name, type, schema, and most importantly, the code. Using this approach you can also format the code the way you want when saving it to a file. I always make the scripts so they don’t fail so I prepend the necessary header code and change the create to an alter command before saving it.

File on Github at: https://github.com/kemiller2002/StructuredSight/blob/master/GettingProcedures/GetProcedures.ps1

Mockups – Now with moving pictures

Wireframing applications are great for creating quick visuals of what a screen or series of screens may look like. mockup The quality of the picture compared to the time required to create it is priceless, because no one spends too much time creating a visual display which will ultimately change and be discarded after the team creates the final product.

There are a lot of tools which create quick displays of user interfaces. My personal favorite is from Balsamiq . It’s easy to create mockups of different screens Button Link and Balsamiq has a way of linking mockups together showing the progression. Conveniently there is a presentation mode should someone need to demonstrate it to a group.

The issue with this is that everyone in involved in the decision process still needs a license and know how to use the application or people must meet and those responsible for the design must explain it. Even if everyone is in the same office this still can be a cumbersome task, and furthermore making decisions based on something seen for the first time doesn’t allow one to reflect on what’s presented.

Combing the linked screen ability with video capture software allows you to quickly create videos showing the progression of an application. Although I prefer the SnagIt interface a little better, a program like CamStudio is free and does the job. Now you can email the video or post it to an intranet, and everyone can view it at their convenience and respond at their leisure.