I hate resumes

I hate resumes. I hate creating them. I hate that potential employers expect me to have one, and for it to be current. I find it hard to believe that resumes still exist with all the communication and social technology we have today. Right now, my resume is just a copy of my LinkedIn profile because I hate writing resumes that much. What does a resume do for a potential employer that looking at a LinkedIn profile doesn't? Even Facebook have a place to list where you have worked, at what position, and for how long.

I should really state my problems with resumes instead of just ranting about how much I hate them.

1) They don't do anything better than other forms of communication. In fact, they don't even replace other forms of communication. Resumes are just another useless step in the communication chain. They don't introduce you, that's what your cover letter, or email, is for. While resumes summarize your job experience or skills, the letter or email you write can do the same thing, while also showing off your ability, or inability, to communicate well. Also, most professionals have a LinkedIn account, or something similar (that may be a lie, I don't know of anything similar to LinkedIn, but if there is I don't want them to feel left out). I have many recruiters email me because they found me on LinkedIn. As I said before, my resume and LinkedIn account are the exact same. So why do I need to provide a resume as well? Can't you just send your client a link to my profile, it's public for a reason.  Also resumes can't answer any questions a potential employer may have about you. Those are what interviews are for.

2) They are too general. If someone plans on sending out resumes to lots of different jobs, they tend to use the same resume. This means that the resume is generalized. They doesn't make you look as attractive as someone who may have tailored their resume to be more appealing to the specific job. Even with the tailored resume, they do tend to come off generalized. They are supposed too. The resume represents you. Many people just want a job (although some only want a specific job, so their resume tends to be more specific), but the good jobs don't want to just hire anyone, they want a specific person. In fact, it is probably easier for the company to use some sort of network to search for people with specific skills who may be looking for a job. I wonder if such a network exists. Oh yea, LinkedIn.

3) You can't tell anything about a person without ever talking to them. A resume only states what that person has done in the past, according to that person. No one ever hires someone based off their resume. They give out interviews based on resume. Actually, that's wrong. They contact people based on their resume, either by email or phone. There they will ask a few questions to make sure the person isn't totally lying about the skills they have, and THEN set up an interview.

I think it was Leonardo da Vinci who wrote the first resume, and he wrote it as a form of introduction. I don't see how a quick email with a link to a place with more information about you (once more LinkedIn, no they aren't paying me for this post…I just use it) is any different. It seems way easier to me, especially since I tend to lose my resume file all the time or it is horribly out of date for some reason. Having LinkedIn is even better because now I get contacted about potential jobs, although it is starting to get a bit annoying, and I've pretty much stopped responding to anything that doesn't look interesting to me, which is pretty much ALL of the jobs I get emailed about.

I'm going to see if I can get anyone to try to hire me without using an resume. Sounds like a fun challenge.

I understand that many companies won't look at you if you don't use a resume. By all means, don't not use one (double negative for the win), especially if it is a job you really really really want. It is a small hoop to  jump through. Resumes had their place back in the day. Back before email was a regular thing. I just feel like the resume is an old fashioned and inefficient way of doing things, or maybe I just hate writing them that much.

Are you done yet?

I would like to start this off by saying that not every story I post here is a true story. There are almost always exaggerations, since they get the point across the best, and the people, places, and companies involved are probably not who you think they are. I've worked in plenty of places with plenty of people.

So...I once had this kind of conversation:
Other Person: "Do you have everything checked in to TFS?"
Me: "They aren't done testing yet, so I don't know what needs to be fixed."
Other Person: "Well...we need to move to staging so we can get the release out."
Me: "Ok, but we need to test our stuff first and fix the bugs they find. They just started testing today."
Other Person: "Well, you think you can have all the bugs fixes done by 12:30?"
I look at the time.....it is  just past 11:30.
Me: "I can't tell you that, because I don't know what bugs there are....because they aren't done testing. They probably won't finish testing today either. "
Other Person: "But we need to go to staging. How about you fix what you need to fix and just ignore anything they tell you they need fixing for this upcoming release then"
Me: Sliently screaming and cursing.

Now some back story for this little conversation. We have a one month release cycle. There is a date for a code freeze, the day where all of our code for new features and changes to old feature need to be in by. The next day, a new build is supposed to be built for testing. From what I gather is SUPPOSED to happen, we get a week to test the new code / fix bugs, and then it moves to "staging" and then live right after that. So generally three weeks of coding new stuff / fixing bugs that have made it to production and a week of debugging new code. (I don't know what the actual schedule is...nothing is documented). What happened here is that the guy who is supposed to do the test build didn't get to it until Friday...which is basically our whole testing week. Tt doesn't matter to him though, different employer and all. So the move to staging was supposed to be that Friday, the day he did the test build. In certain places of employment, this isn't a problem, since they have a test environment that they themselves control. We do not. We are subject to the whims of others, and it makes me mad (we don't even have proper testers either).

Here are some of the problems I have identified that this story and conversation present. The first being a delay in the schedule....but not moving the deadline. When you have something on your schedule..say like updating an application, and it can only happen after something else on your schedule...like testing said updates and correcting bugs....when the first something is late or delayed, the thing that follows is automatically behind. So if you are five days late to making the build for the test server and we need and/or get five days for testing before moving to staging, then the date to move to staging gets pushed back five days, otherwise you end up with a pile of s**t. Good example would be the ACA Exchange website. I think they only had like two weeks or so for testing. I could be wrong about that, but it wasn't nearly enough time. And changing the requirements of the product with less an a month to launch means you need to push back the launch date...or not change the requirements (yea, that would have been easier). If you don't have cushion days, you can't keep your schedule if a single thing ends up falling behind. Cushion days are extra days to get stuff done in case something like this happens. They are a bit like hurricane days that schools get in Florida. They are extra days off for the students...unless a hurricane comes in and wreck the hell out of the school, making it close down. In that case the student makes up those days the school were closed by attending school on the hurricane days.

The other problem with this conversation is asking me when the bugs will be fixed. I can't possible know that...especially if I don't even know what the bugs are! That is like asking a physics student how many sheets of paper they need to solve a problem when they don't know what the problem is. It could be half a sheet of people....or it could be 10 sheets of paper. Depends on the problem. It is the same with coding, a bug could take 10 seconds to fix, it could take the entire week. I can't know until I see the problem. Every coder does things wrong from time to time. It happens. If you can't fix the bug by the time you are ready to go to staging, you roll back your changes and that feature isn't released. Simple.

The correct course of action here would be to roll back our changes and not release any features since there was no time to test. That isn't what happened. In fact, I'm not really sure what happened. Testing was still being done the next week and I was still checking in bug fixes the next week. I guess they gave us more time to fix stuff. Which makes me wonder why I was being hounded with that conversation in the first place. I suppose that is a post for another day though.

Beware the literal string!

One of the most frustrating bugs in programming (for me anyway) is caused by mistyping a literal string. It is just so hard to catch because of the way the brain works. When you mean to type 'Denied.aspx", but you ended up typing "Denied.asp", you see "Denied.aspx" when you read it over. That's because it is what you expect to see. This is why it is sometimes necessary to have another set of eyes to look over your code. If someone spots a mistake like this in your code, don't worry they aren't smarter than you and you're not a bad coder. What I do is when I finish writing some code, especially code that involves literal strings, I let it sit for a day or too before going back and looking it over. Fresh eyes are more likely to spot this mistakes because what is SUPPOSED to be there isn't at the forefront of your brain.

The literal string gets really tricky when you are using the same exact string in more than one location. At this point it is makes sense to create a constant string variable and put it in there. I think that even if it is used in only one place it should still be put in a constant variable (the story I will share in a bit will show why I feel this way). The variable name could even be the string that variable holds. As long as you are using a modern IDE (I'm working on Visual Studio now) then your IDE can become a sort of spellchecker when using the constant.

Here is my latest literal string story:

My code needed a way to redirect a user to a access denied page if they weren't authorized to access the page. Pretty simple, a simple Server.Transfer("Denied.aspx") worked fine. (I could not use Response.Redirect for reasons beyond the scope of this blog entry). However Server.Transfer throws a ThreadAbortException, which can be a bit confusing since we log all exceptions and treat them as errors. While Servier.Transfer was probably the most correct way of coding this, we REALLY didn't want that exception showing up in logs. The solution I can up with was using Server.Execute instead.
     
     Server.Execute("Denied.aspx");
     Response.Flush();
     Response.Close();

What this does (as best as my knowledge goes..I  don't really want to be considered an expert on this) is 1) Server.Execute() = run the page and add the output (the rendered html that the client recieves) to the output buffer, 2) Response.Flush() = send whatever data is in the output buffer to the browser (execution of the current page request still continues and more can still be added to the buffer, and 3) Response.Close() = this closes the connection the browser used to make the page request to the server, meaning that the server can no longer use that connection to send anything else back to the browser (I'm a bit effy on this part, but it is how I understand it). Now I'm not sure if this is the proper way of doing this, but it doesn't throw an exception and seems to work. So I had

     if (conditions not met for access)
     {
          try {
               Server.Execute("Denied.aspx");
          }
          catch (Exception e)
               LogException(e);
          }
          finally {
               Response.Flush();
               Response.Close();
         {
    }

I then decided that this would be useful as a standalone function in a class built for general-use functions. The class was called GeneralFunctions and the function I decided to name Deny(); So now I had

     if (conditions not met for access)
     {
          Deny("Denied.asp");
     }

and my Deny function looked like

     internal static void Deny(string DenyPage)
     {
          try {
               Server.Execute(DenyPage);
          }
          catch (Exception e)
               LogException(e);
          }
          finally {
               Response.Flush();
               Response.Close();
         {
    }

Oops. Seemed like I left the 'x' off of "Denied.aspx" when calling my function. I was now getting an HttpException saying that the httphandle could not execute on the child request. I'm not going to lie, I had very little clue what this meant (in this case, it means that the file doesn't exist!). Now i haven't noticed my mistype yet,.So I reverted back to the old way. I did this via comments because I don't want to forget what I had typed before.

     if (conditions not met for access)
    {
         Server.Execute("Denied.aspx");
         Response.Flush();
         Response.Close();
         // Deny("Denied.asp");
    }

Ok, no exception there. I kept switching between having those three lines in the if statement and moving them into the beginning and end of Deny() and commenting and uncommenting Deny(). Finally I commented out the whole try..catch block in the Deny function while I had the trio of lines from the if statement in there and saw no exception. But even then I STILL couldn't see my typing mistake. I didn't see it until another coworker showed up and distraction me for a bit. When I went back to look at my problem...blam! All of a sudden I could see it clear as day.

It took about an hour, maybe more for me to see it. When I did see it, the first thing I did was put that bad boy into a constant and used it instead.

     constant string ACCESS_DENIED_PAGE = "Denied.aspx";

      if (conditions not met for access)
     {
         Deny(ACCESS_DENIED_PAGE);
     }

While I know that this small problem doesn't mean that I'm bad at coding, but its nice to know I'm not alone. So if you have a story about a typo messing up something you were working on, feel free to share below, and we'll all have a good laugh together.
       

Documentation....A huge hassel.

I once failed a class because I did not create any documentation to go with the program I had coded. The class was Business Programming - C++. The only assignment for the entire class was to build a database backed program. I choose to do a bookstore inventory program. I wrote the program during the final weekend of classes. When my professor went to grade it, it crashed. I didn't think he would try to enter a string when I was asking for a number. Why would he do that? Because end users would do that, that's why. He gave me an F, not because the program crashed. He expected it to crash. He gave me an F because I didn't provide documentation on how to recover from a crash, or any documentation on how to use the program. I thought it was obvious. NOTHING is obvious to a user, lesson learned.

As I progressed through school, documentation was always a key part of whatever programming, web design, or software development class I was taking. Comments in code? Better be there, or points off your assignment. Wireframes for your webpage....half of the assignments for one of my classes.

At one of the jobs I've had, I asked if there was any documentation for the program I was going to be working on. I was laughed at. For another project the user manual was five years old, which is way out of date, and I was told that there was no point in referring to it at all.  I'm sure that this is not the case at every company, but most of my co-workers seemed to think that this was totally normal.

I think that documentation is a very important part of a project. This is why a significant portion of some classes are spent on how to do documentation correctly. I really wish we had a design document for my current project. Not so that I know what I'm supposed to do doing, I already know that, but so that I can point to it and say, "this is why the program was created this way". Documentation takes time to create though, and time is money. I work in what I feel is a volatile environment, one where changes to program requirements seem to happen on a regular basis. This is not a productive environment to code in, at all. This is usually the result of the customer not knowing exactly what it is they want, or the lack of a design document and a process to go through to get something changed on it. But what’s done is done and there isn't really a good way to go back and fix it. Not without moving backwards, which is something you never want to do. It kills morale, and in the case of doing contract work, makes it seem like you've wasted time and money. So the solution is to keep trucking forward.

So why don't we start doing documentation? Spend a little less time on coding in order to get our documentation to where it should be? Because of the volatile environment. Trying to document something in such an environment is a bit of a time waster. I know because I tried. I wrote on documentation on a process. It took me between a week and a week and a half to get it the way I wanted (wasn't the only I was working through, so less than 40 hours). Within a month, it was out of date and needed to be updated. Now, do I spend another week to change it, just to have it go out of date on me again? The process it was documenting was a relatively minor one, and would only eat up a day of my time to explain or show how to set something up. We have a pretty small team and this process wouldn't have to be gone through many times by the same person. So, it was decided that this particular piece of documentation was more trouble than it was worth.

I'm not saying that documentation isn't important. I think it's extremely important in getting a project off the ground. However, once a project has gained some stream, the usefulness is diminished to the point where the time spent to create new documentation hampers the ability to make progress. The classes I took where we were forced to create wireframes for our web applications or programs before we started working on any actual code were dead on. Not just with how important documentation is, but at what stage it should be done. In the beginning of the project, on the upstream, where changes are easy to make because there isn't much to change. It should be part of the overhead cost of doing a project, not an ongoing cost, because the ongoing cost is so much more expensive.

So...documentation is good, as long as it’s done as soon as possible and isn't subject to change very often. Otherwise, it’s really more trouble than it’s worth, as out-of-date and wrong documentation is often worse than no documentation at all since it can lead people astray and waste their time. And time is money.

Almost a whole year later...

It's been almost a year since I've graduated from UCF and started working at my current job. The academic world and the professional world of programming are similar but different at the same time.  I still know many people who are still in college studying programming (or soon will I hope). They are sometimes baffled by the way things are done where I work as opposed to how things are done in the classroom. This isn't to say that the classroom way is wrong, or that the way its done where I work at is wrong, they are just different. This is mostly because of the priority shift of what is ideal in the classroom setting as opposed to the more realistic or "cheaper" way things are done in the workplace. I'm just going to sum up some of the differences I've noticed thus far here and in the future go into further detail of each. These are my own unique experiences and I'm sure aren't the same everywhere.

1) Documentation....often an assignment itself leading into another assignment in school. A huge hassle no one has time for where I work.

2) Group Projects....in school if one person doesn't pull their weight, it seriously sucks for the whole team. Where I work, as long as you do what you're supposed to be doing...you're golden.

3) Silly mistakes.....they happen and are expected in school. At work....at best they seriously annoy your coworkers.

4) Time management and Organization....all those classes about college success you thought were useless to get through college, pay attention because after college these skills and habits can really save your bacon.

This post and the ones that follow are more about general purpose development and not isolated to writing code. If you're looking for code I'll get back to it one day. This post was really to try to get me back into writing stuff, hence the lack of content here.