Do I Need a CS Degree to be a Software Developer?

A degree in almost every field only indicates that you have met a minimum set of requirements. It is not an indication of proficiency in the practical application of the knowledge you gained through your degree. The degree is still valuable though and we should not underestimate its worth but we should understand its limits.

First, great software developers come from all walks of life and do not need to have a formal education. We are in one of the very few professional fields where this is true and accepted. Most other fields do not provide people with the opportunity to self-teach the subject matter. For example, you probably don’t want a surgeon who has only read about medicine but never practiced it. Software development has a low barrier to self teach in that you can buy a computer for little money, pick up a few books and start writing code. That code may be terrible at first and you are not jeopardizing anyone’s life either.

Second, really smart and dedicated people have the ability to learn how to be software developers and are generally encouraged by the community. These people can take the time to learn the craft and become highly proficient. Then get a job and hone those skills. This is true of people with and without formal academic training.

Third, people with a degree in computer science, or in a multitude of other curriculums that require programming, are not necessarily going to be better programmers than the self taught. It is a matter of dedication and aptitude to the field. There are plenty of ridiculously bad software developers and CS graduates out there. The fact that they got a degree always frightens me.

Fourth, graduating form a top-tier computer science program does not mean that you are going to be a good software developer. Some of the top-tier schools use teaching languages rather than practical or rigorous languages, such as Java and C/C++. Practical languages get you a job if you are proficient. Rigorous languages, provided they are rigorous in the use of the machine rather than just having an overly complicated syntax for simple operations, teach real data structures and how to truly control the machine.

The value of formal computer science and programming courses are that the exercises and the reading materials are different from those more commonly available to the rest of the public. The books you generally find in Barnes and Nobel have a goal of getting you programming or solving a specific set of problems in the shortest time possible. These books don’t always go into the theory or the “why we are doing this” bu instead focus on how to do it. 

That’s what the text books and classes are supposed to do. The experience of guided instruction, programming exercises and text explaining theory are supposed to teach why we do the things we do. The implementation, or the how we do it, is an entirely different problem that is often easier to solve.

For example, I could ask you to write a Java program that takes a paragraph of text and displays each sentence with a count of the spaces within it. It takes about ten minutes to write the code. It isn’t hard at all. You can find out how to do it by simply searching the web.

Now, let’s say that I want you to perform string replacements for any expression within the paragraph bounded by curly braces. Then let’s say that I want you take what is within the braces and determine if it is an arithmetic expression and replace the expression with its results. The example paragraph may have a line that looks like “3 * 10 = {3*10}” and the output is “3*10 = 30”.

Can a person without a formal education in computer science do this? Sure, but pretty much any CS student can do this as a result of just the required courses. Especially any graduate student who has taken a compiler design class. 

The problem for the self-taught is that the commonly sold texts don’t go over these subjects very heavily. These books often cover an existing API or a technology that makes it simple to accomplish the task. It’s the difference between knowing how to use Apache Velocity vs writing Velocity.

Can the self taught learn these things too? Of course they can! The question is whether you will ever be exposed to the material and whether you will have the depth of knowledge that  one gets from a formal education in a subject. This impacts how far you will advance in your career and the kinds of problems you will be asked to solve later. 

Just to be clear, I know many non-CS software developers who are great architects, CTO’s, VP’s and leading software developers and they all have the same depth as a CS graduate student if not more. The difference is that they had to seek out the information rather than having it handed to them. Their dedication and intelligence is what led to ever more challenging tasks and their success. I have known a large number of CS and non-CS developers that were inept too. Their lack of dedication or intelligence led to their mediocrity and relegated  then to equally mundane tasks.

Being a Developer During a Recession Part 2

A year ago I wrote some thoughts on preparing and weathering a layoff. I reread it this week after meeting a fellow in a hotel lobby. I was there with my wife and son because we had lost power in the recent ice storm that struck the north east. We lost power for several days and needed to find warm places to stay. He was there for the same reason.

He was a tech writer for a Massachusetts company for ten years. He had been laid-off just a week ago. He was going through loss and anger at being forced to go away. His income was taken away along with pride and purpose. You could see the pain on his face and it struck a chord within me.

My layoff was not an easy time, especially the months just after the layoff, because I felt terribly betrayed, bitter and lost. It was winter and its hard for me to be cheerful when the days are short, grey and cold.

I lived in a condo about an hour north of Boston and fortyfive minutes away from my old job and the friends I had worked with for nearly three years. I was single and a little overzealous in my love for writing code, so my work became my life. One day I was evicted from my life and things felt pretty bleak.

I watched in 2002 as every other department had significant staff cuts. The development team wasn’t going to be touched because we were in the middle of releasing a “game changing” product that would seal the company as the leader in its space. It didn’t take a genius to figure out that layoffs in engineering would follow the release. It was of a question of when it would happen rather than if. I stopped spending and saved everything I could except for going out for dinner and drinks with friends.

The year leading up to my layoff was tough. Everyone was working long hours and weekends for months on end. Vacation time had been canceled. Getting more than one or two consecutive days off was difficult.

I was a principal developer and had several critical components to develop. I was always writing middle-tier core code that nearly every other component called. I designed the entire security component and wrote all of the method level security methods. I also wrote the interface and all the components for our content management system, which also included a fairly complex collaboration model that managed an editorial process for content publication.

Writing so much core code gave me a false sense of security. Who would seriously layoff the only developer that knew both security and document management. Getting rid of that developer would be a huge setback to any project. Of course, you have a lot more time to learn what that developer wrote after you release the product and have six or eight months before your next release.

The first round of engineering layoffs occurred in October of 2002 after a September release. We all knew who was being laid-off too. The management team scheduled reviews and raises for all the employees that they were keeping. There were eight people that didn’t have reviews scheduled. It was terrible to watch one of my good friends break down and cry every day for two weeks as she waited to be let go. She was the sole income for her family of of four. They were kept on for about three weeks before they were let go.

The second round consisted of a couple of great UI designers and a few people in another office that I never met. The UI designers built a really amazing user interface and kept a product with dozens of web pages looking cohesive and made the work flow from one task to the next logical and elegant.

Round three had lost five people, myself included. There was a product manager that was pushed out. All five of us were hard working and had made significant contributions to the product.

I found out about my layoff about a week ahead of time because the VP of Human Resources left a memo on his desk with the five names and a helpdesk guy was called in to work on his laptop. The helpdesk guy saw the names and told me I was on the list. I found out in the parking lot while another friend of mine and I were heading out to grab dinner and drinks. That was a night of very heavy drinking.

That following Monday the VP of Architecture called me into his office. He wanted to go over the document management system and document how it worked so we could teach the other developers how to work on it and improve the system. I smiled and said “Ok, but if you are going to lay me off, please do it on a Friday. I don’t want to have to drive all the way down here on a Monday and then drive back.”

There are statistics that show that suicides occur more often if you lay a person off on a Friday than on a Monday. I wasn’t going to commit suicide over that job so I was planning my weekend ahead of time. I had an idea for a new product and just needed time to write it. I knew I would have plenty of time to work on it now.

I spent the week writing up documents and having daily talks with the VP of Architecture and his chief architect. I liked both of them. It was hard knowing that I wouldn’t see them again. The meetings would go on for hours and then I would work on the document. In the middle of the document I wrote something like:

“I’ve spent this week writing all this documentation but I know you are not going to actually read it. It is really pointless for me to be doing this and if I drew some diagrams you may have a shot of comprehending the mess you are in. Unfortunately, the only tool I has is powerpoint, which isn’t known for its high quality diagraming technologies. Good luck!”

That was the extent of my sabotage. I finished everything on Thursday and went home knowing that the next day was to be my last.

I got in around eleven AM and asked my friends if we could go to lunch. I mentioned something that it was important and meant a lot to me. I told one of my friends that I was going to be laid off that day and he thought I was nuts until the VP of Architecture swung by and wanted to meet with me.

I wandered into the VP’s office and was handed my package, which I read through and tried to keep calm. I was gasping for air every time I spoke. I could hardly get the words out when I needed to ask a question about health insurance, severance or my remaining time off. My heart was pounding so hard. Then I got up and asked if I could say good bye to my friends. I was allowed that honor because I had put in so much time and effort, everyone else was walked out the door with little time to clean up their desk.

I swung by a few desks after lunch and said my goodbyes. I went home and drank a bottle of wine and watched some bad science fiction movie. I had to watch it a second time the next day because I didn’t remember anything from the previous viewing.

I started writing code that Monday on an application analytics platform. I wanted a tool that could tell me the features and the order that customers executed in a given product. This would tell me which features customers actually cared about and would let any developer prioritize the heavily used features over the rarely used. I wanted the reports to be web accessible. I needed a way to collect the data from an arbitrary application and dispatch it back to some import server that would dump the data into a database. I needed an analytics engine to convert the raw data into summary information. It was something big enough to keep me really busy.

It was a great project for me in that I didn’t know UI development at all but knew EJB 2.0 inside out and was also decent with database work. I spent a year writing code and living off the money I had saved.

I buried myself in work for weeks. I would get up at around eight AM with no alarm, eat breakfast, write code till two PM, shower, eat, write code until eight PM, eat, watch a movie and go to bed. I edited my spending habits to food, utilities, healthcare and mortgage. I had to cut the house cleaning service. I cut beer and going out for meals. I stopped buying stuff almost entirely except I did buy a new desktop computer to build my new application.

I kept in touch with many of my friends via email but I was pretty dedicated at developing my own project. It’s not entirely true that I was dedicated. I was incredibly hurt by being laid-off and the way I dealt with that emotional pain was by hiding in work of my own design. I was angry at the company where I had sacrificed and worked so hard. I had given up weekends, nights and even dental appointments because I felt needed and couldn’t let the team down. I had hardly dated or done anything with people that weren’t in the company. It had become my life as many of us would go out to dinner or hang out together regularly. I missed my friends terribly.

I worked on my project for about three months before I hit the wall. I looked like a wreck. I would shave only every couple of days. I was dressing as a flannel clad Hugh Heffner though I wouldn’t go outside in that outfit. I hardly went anywhere except to the supermarket. Most of the light bulbs were burnt out but I knew where everything was even in near total darkness. Only the kitchen was kept up lighting wise. I did keep the house pretty clean though.

Things got to a point where I couldn’t code well anymore. I was getting wrapped up in simple problems and looking for really innovative and exciting solutions. I realized that the solutions were not practical anymore. They were complex and strange but looked like they would work really well. I was losing or had lost perspective. It was time for a vacation.

I didn’t go anywhere. I stayed at home and cooked. I was a terrible cook and that’s why I ate out so often. I ate out every night before the layoff. Was it expensive? Only marginally so since factoring the cost of electricity, food, water and cleaning that dinner out only cost me a buck or two more per night. That came out to somewhere between 30 and 60 dollars I could save if I cooked at home. I cooked dinner every night and ate the left overs for lunch.

I ended up going to the supermarket pretty much every day. The idea was that I only bought what I could carry in one trip from the garage to my kitchen. I also didn’t know what I would feel like eating from one day to the next. It felt better to be around people anyway.

I watched “The Recruit” one night and an idea lodged into my head that I hadn’t been reading very much fiction in the past few years. I wanted to read some Kurt Vonnegut because of a reference in the movie to ice-9. I was hoping to cheer up by reading his works. I got in the habit of going out to lunch and reading while I was at the restaurant. I was able to go to a different restaurant pretty much every day and that was fun. I cheered up a lot, especially after changing out all the lightbulbs.

Spring was rolling in. I went back to hammering on the keyboard to build my application. There was a UI, a middle tier and a database that were coming together nicely. Writing the UI is rather difficult for me still but that’s where UI development really started. The product was almost in a demonstrable state.

My schedule changed a little. I was still up at 8, breakfast, shower, Babylon 5, code, lunch, code till 7, cook, eat, movie and bed.

Reading Vonnegut was brining me down so I thought I would cheer up with a new author. I wanted to read something that had influenced the way literature was written. I reread Jack Kerouac’s “On the Road”, which is still one of my favorite books. I started reading Hemingway and read three of his novels before stopping. Why? Why did Hemingway’s chicken cross the road? To die, alone, in the rain. That’s why. Don’t read Hemingway if you are feeling down.

I was feeding data into my application using some test cases and now I wanted to get the system more automated. I used Java byte code injection to instrument a target application. Getting injection working is simple but getting it to work in a wide range of applications and perform was far more difficult. I spent a bit more than a month getting everything to right.

Looking for a job was also a big aspect of my life. I would hit the web and visit a number of job sites like HotJobs and Dice. I also talked to a recruiter and worked with him. I had only one interview in six months. It was with a CMGI company. The company went out of business a month later and sold off all its assets. All the employees were out of work.

You could go on to HotJobs and do a search of Java development jobs in the summer of 2003 and get back zero results in the Boston area. Right now you can find around 110 on HotJbos and 438 on Dice. I kept looking and submitting resumes to meet unemployment insurance requirements, but there was no chance of actually finding a job at that point. Congress kept extending benefits out to a full year. I thank God for that.

A friend of mine and I decided to launch a company with my product and look for some kind of financing. We met with SCORE, which was a complete waste of time. They are fine if you want to start a restaurant but they are out of their league with tech startups. Things have changed in the way software is developed, financed and sold such that their experience is not generally relevant.

We did get a few chances to pitch the idea to investors. It didn’t go anywhere. They would nod and think that it was an interesting idea but they were not interested in investing. All the entrepreneur wannabes should take note of this one statement: Investors invest in people, not ideas. We did not meet their vision of investment worthy individuals.

I was not put off much. I kept working because there was nothing else to do. I did spend more time during the summer goofing off though. I had Friday lunches on the deck of this restaurant and have a beer too. I decided that I could reintroduce beer into my nightly diet.

That summer I got a number of charity requests. Calls from my old college asking for money. I told them that I was on unemployment and couldn’t afford a donation this year. They suggested that I go on a payment plan. How can a person even suggest going on a payment plan to fund a charity like a college when you are concerned with paying your mortgage, healthcare and being fed? I haven’t talked to the college since.

I put up a dating profile on Match.com that August. I changed the profile’s “about me” section about once a week hoping that I would eventually write something interesting and get a nibble. It worked too, I was having a number of email conversations and that was fun.

Fall started and I launched the product on the web. I was not about to give up on the idea so I just took a different direction. Nibbles? No, I could count the downloads with my fingers. Still, it was getting out there and every download gave me hope.

In October I traded emails with this one gal that winked at my on Match.com. She was a little goofy, brainy, had a great sense of humor and she stuck by me as fall turned into winter. Our dates were so fun. She would go to her work and I would keep working on my project. Life was becoming so much better.

January marked the end of unemployment insurance. I had plenty of savings still so I wasn’t very worried. I was emailing more resumes and kept developing the project. I had a few interviews and they actually downloaded the project. The UI was pretty bad looking back at it, but I was getting back into the groove of being interviewed and it helped get me in through the door.

One morning in April I saw a job on Craig’s List. I put in the resume and went from my home office to the basement to do some work. I got a phone call from the recruiter I sent the email five minutes to and she was scheduling an interview. I got the job and a surprise: I got my old salary after being out of work for over a year! It was a miracle as far as I was concerned.

Working on the project kept my skills sharp. I had gone deeper into a number of technologies and worked with many new ones. It was wonderful to have a new job thanks to the project.

I didn’t stop with the project though. I showed it to this one guy and he showed it to another and pretty soon we were raising money. It took a year and we raised $750,000 by the end of the Summer of 2005. It was huge. He was the key, he was going to MIT Sloan School of Business and he made all the financial connections. I kept writing code.

My girlfriend and I got married in October of 2005. We went on our honeymoon and came back to my new company.

The experience of being laid-off was devastating at first. It was so gut-wrenching to be evicted from my life that I can’t put it into words still. I can’t explain the anger at having given so much and then be told that we don't need you anymore. Being laid-off is a crueler thing than most people can understand.

It worked out in my case though. One could argue that it was the best time of my life and that only the first three months were really bad. That actually isn’t true as I still reflect on it with bitterness and I’m not sure I’ll ever be free of it.

We read a lot of advice on how to keep your job during a recession too. Many say to be the critical employee that the company cannot afford to layoff. Companies layoff C-level staff all the time and they are supposed to be the most critical employees in the company. Only a few companies will see the value of a developer being greater than some executives.

I have only four pieces of advice. The first is to save your money. The second is to find a way to keep your skills sharp. The third is to find a purpose to drive you forward everyday. The fourth, and most important, is to be thankful for what you have because there are those that have far less.

GUIDs as Primary Keys or How to Walk Into an Argument

I generally work on two kinds of projects: the big enterprise web application and the tiny startup web application. The requirements and processes for building these two projects are distinct. For example, the database in a big project could easily be Oracle or DB2 while a tiny or mid-size project may run on MySQL or SQL Server. Other differences include hardware and staffing resources.

Before we get too far, I should make a note about the above databases. I personally have yet to encounter a project that cannot be implemented using MySQL. I have built analytical web applications running hundreds of millions of rows in a single table and it worked and performed well. There are limitations in tuning but generally I have found some level of snobbery with the DBA’s thinking that MySQL is just a toy DB. A word of caution to them is that Toyota was once seen as a mediocre, unreliable, rusty piece of junk and now it is considered one of the most reliable and financially stable auto makers in the world. Things really do change over time. Back to the main subject.

Big projects often have larger budgets, more resources, more requirements and often have a longer development cycle. That longer development cycle may include more time to understand the data model and the production environment and thus produce a executable design.

Small projects often have a small budget, fewer resources and may have much less planning. These projects may also be cash flow constrained, meaning that you want to spend as little per month as possible while still delivering a service that customers will buy.

Databases and primary keys come into play when you are working with a small project that may become big and outgrow its hosting needs. Moving a physical server is relatively easy provided that you can schedule some downtime. You may end up having to replicate the database on a new server and bring up the new server at the new hosting site. There will almost certainly be some data reconciliation process after the transition form the old server to the new.

A bigger problem occurs when you are really small and trying to go from one web provider to another. You may have a Virtual Private Server (VPS) at one hosting provider and have to migrate to a dedicated server with a new provider. This migration process is more difficult and requires more downtime.

Its more difficult in that replication is not an option. Some will argue that database replication is tricky unto itself. However, to me there are only a few things more painful than exporting a database and then importing it somewhere else. The easiest migrations used a GUID as the row ID. This is especially true when I’ve had to merge two or more active databases.

I was planning on writing extensively about the virtues of using a GUID as a primary key and then I read the following posts:

   1. Brian Aker, "Brian "Krow" Aker's Idle Thoughts - Myths, GUID vs Autoincrement," http://krow.livejournal.com/497839.html.

   2. Jeff Atwood, "Coding Horror: Primary Keys: IDs versus GUIDs," http://www.codinghorror.com/blog/archives/000817.html.

   3. Mike Malone, "Database Design: Choosing a Primary Key - I'm Mike," Blog, I'm Mike, http://immike.net/blog/2007/08/14/database-design-choosing-a-primary-key/.

   4. Jimmy Bogard, "Designing primary keys - Jimmy Bogard -," http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/06/04/designing-primary-keys.aspx.

   5. Joe Celko, "Identity Vs. Uniqueidentifier (Newbie question) - microsoft.public.sqlserver.programming | Google Groups," http://groups.google.com/group/microsoft.public.sqlserver.programming/msg/6d61dbf80d6f0fb6?hl=en&lr=&ie=UTF-8&oe=UTF-8&rnum=14.

   6. Jimmy Nilsson, "The Cost of GUIDs as Primary Keys," http://www.informit.com/articles/printerfriendly.aspx?p=25862.

   7. Kenneth Downs, "The Database Programmer: Database Skills: A Sane Approach To Choosing Primary Keys," http://database-programmer.blogspot.com/2008/01/database-skills-sane-approach-to.html.

   8. Peter Zaitsev, "To UUID or not to UUID ? | MySQL Performance Blog," http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/.

Jeff Atwood’s post is particularly interesting because of the huge number of comments and most of them are against the use of a GUID as a primary key.  The most common reason against GUIDs has to do with large tables in that search performance degrades more rapidly than autoincrement or sequence integer IDs. Some of the other posts argue that the degredation is not significant enough to warrant concern.

Others argue that the primary key should be an integer but the end user should see a GUID as that makes it easier to obscure the layout of the database. I’m not sure I buy that argument since it should still be pretty easy to find a given row using that GUID. I think this developer was really trying to create a level of abstraction from what a user may bookmark from something that code could efficiently work with. The strategy would allow the developer to change his primary key without impacting the user. However, it would seem reasonable to ask how much benefit there really is to having both keys when the GUID alone is enough to do all the work?

My thought on this is that the GUID is slow to look up, but once it is loaded you have the object’s real ID and hopefully it will load faster in follow-on queries using that numeric ID. A smart developer may also ask why someone would be loading a record once by GUID and then reloading repeatedly by numeric ID. Shouldn’t the original load be enough for most applications?

Many of the posts have a shared viewpoint that GUIDs do not significantly impact performance on small tables but fail to say how many rows makes a table small. They often agree that DB merges are easier using GUIDs.

My personal viewpoint is that I have not measured a significant enough performance impact to dissuade me from using GUIDs in a project that I know will be migrated to a new hosting provider. I think it is fair to use autoincrement integers or sequences when you know your database will never have to be merged or migrated and on tables with more than 10 million rows though the quality of the server may increase the number of rows.

This opinion takes us to the second part of the time: How to walk into an argument.

Computer science, like all of science, allows developers the freedom to form an opinion and later a hypothesis about how something should work or be done. We have opinions on nearly every subject and some of them are polarizing. A GUID as a primary key is one of those polarizing subjects. 

I have witnessed an explosive argument between developers arguing for and against GUIDs and both of them citing anecdotal evidence only that there is a performance issue. I have personally been involved in a discussion where the other person dismissed the very idea of GUIDs without further discussion. That same project had a significant delay as a result of a data migration problem that would have been entirely avoided had we used GUIDs.

As I said, I was planning to write more extensively on the virtues of GUIDs and then I read the other articles and realized that this is not a back-and-white solution. It is a solution that is ideal in only some situations, just like a hammer is only really useful when driving a nail or banging something into a new shape. It became clear that this subject is highly contested and would become a serious argument.

Walking into a huge discussion or argument over design principles is amazingly easy. One of the hardest things to overcome is that generalizations are often very dangerous without empirical data to back it. Only by taking risks and testing the approach, using real data, can one rule out the use of a particular construct or strategy within a web application. Thus many seemingly unorthodox approaches may actually be valid within the conditions of the application.

My conclusion is simply that GUIDs as a row ID may be perfectly reasonable for your application. It may cause some performance degradation, but the degradation may be insignificant. The only way to know is to test it and compare the performance of the key to a more common numeric key and then balance that against the requirements of your application. The only thing we should not do is dismiss the approach without first confirming that the conceivable issue is a real issue.

Can I Just Change Jobs?

The topic of "Love it or Leave It" from Jeff Atwood is an old one that pops up every year. See these two links:

1. Jeff Atwood, "Coding Horror: Programming: Love It or Leave It,"http://www.codinghorror.com/blog/archives/001202.html.

2. Joel Spolsky, "The Joel on Software Discussion Group - Thinking of leaving the industry," http://discuss.joelonsoftware.com/default.asp?joel.3.718003.14.

Its the notion that software developers are so passionate about coding that they would do the work for free and that anyone who wouldn't is a bad developer. I, after a lot of reflection, agree with this up to a point. I code in my spare time on projects of my choosing because it is something I am interested in and I find it relaxing. It's recreational programming.

There is a misguided notion that coding and software development are the same thing. Software development is a process of requirements gathering, designing, refining, developing, debugging, refining and deploying for the purpose of making money or for academic research. This process often occurs within the scope of one or more teams that have their own hierarchies and procedures for decision making.

The problem with the "love it or leave it" attitude is that it doesn't separate the job from the task. The task of coding is often enjoyable provided you are working on an approach that you don't fundamentally hate. Hate is a strong word for the situation, but most developers eventually get stuck implementing something that is just a horrible idea but we're doing it anyway because we were told to do it. I get really cross in those situations because I feel like I'm failing my own standards even though I am doing what I am told. I feel like I also failed to explain my viewpoint in a persuasive enough manner.

The job of software development can be terribly frustrating depending upon the team and organization. You could have a dictator for an architect who never listens to your designs. You could have a miser for a VP of Engineering or CTO that expects his employees to work 60 hours a week. You could have the most dull job in the world and the code you are writing is not challenging or even interesting. You could have five bosses that compete for your time and get angry when you work on one of the other boss's tasks. You could have three or four cliquey teammates that create unnecessary drama in the workplace. You could be an architect but not have buy-in from the CTO so nothing you design ever gets implemented. You could have a nutty team lead that always wants to take shortcuts in code rather than really fixing a problem. You could have an HR policy that requires a timesheet that describes the work you performed in 15 minute increments. You could have daily standup meetings that take an hour, accomplish nothing, occur at lunch every day and the next round of meetings begins at 1pm. Your manager may take a nap, with the lights turned off in his office, while the rest of the team is on hour 12 of a 14 hour day trying to meet a deadline. Your software developer job could really be a miserable thing.

How many people have seen one or more of the above in their own workplace? I've seen all of these actually happen! A few of them have happened to me. Having five people assigning you tasks and making them negotiate for your time is very trying. That sleeping manager really amazed me but I already had a new job and just wanted to get out of there.

We are fortunate in many areas though. We generally make much more money than the average person. Our salaries plateau early in our careers compared to others, but the plateau is often well above the average pay in your geographic area. We often work in comfortable, climate controlled buildings. We almost always get good benefits like health care, some form of retirement and paid time off. We often get to work on challenging problems that test our abilities. We often get to work with smart people that often care about their work. Many of us have a lot to be thankful for.

Who should we be thanking? Is it our employer? How about teachers? How about team mates? Maybe it's our parents that encouraged us? Our spouses and our family? God? We got to where we are by working darn hard and through some people that supported us. Our job is not easy and not everyone can do it. We give up a lot of free time to master our craft and we often have jobs that require longer hours than almost everyone in the company. We are passionate about our work and expect to be treated and paid well too. And we are thankful to those who support us and stick with us when we are working.

Loving your job and loving coding are two very different things. We cannot sit and judge a person's situation from afar and say that he should be thankful for his job and is whining. Sometimes a job just sucks and it's time to move on. Sometimes we need a reminder that other companies are different and there are better projects, better places and better teams.

There are plenty phenomenal software engineers who are tired of the job and want to try something new. A good friend of mine left software development to become a photographer. He is easily the best software developer I have ever worked with and he walked away from the craft entirely. He codes just for the fun of it, occasionally writing the odd sudoku puzzle solver and thus taking the joy out of the puzzle entirely and moves on to something else. Is he a bad developer? No, he's just done and ready to try something new. How many people do we know that came to software development from some other field? How many of them are good at it and do we call them quitters for leaving the field they started in?

We sometimes take the viewpoint of "code above all else" but we see many that want to have a good job and be able to enjoy other aspects of life. Many of us are naturally inquisitive and need to apply our minds to many different disciplines, which is where we get the art in the "Art of Computer Programming." The art, by Knuth's definition, is the application of many different disciplines in order to code great applications. You need to learn a little accounting if you are going to write Quicken and you need a little expertise in photography and editing if you are going to write Photoshop. We learn to work with others to build a great application. We need to be more than just good at writing code to be great as software developers.

But some of us are tired of all the things that go along with coding as a part of a job. And some of us go off and start our own company because we want to code on our own terms. Others move away from jobs that require coding and become architects, team leads, CTO's and CEO's and yet we don't call them quitters or complain about their lack of coding commitment.

The "love it or leave it" attitude helps no one and labels too many people as not committed enough and opens us to exploitation by our employers. It confuses the job of the software developer with the fun of coding. We code because we love to and we work because we have to pay bills. We are lucky that our work is often on of our favorite things to do, but we are equally cursed when our work demands too much of us and our family. Many of us do not lead lives of quiet desperation but many of us are pulled between the needs of our lives, the requirements of our employers, the dynamics of the team and the love of coding. The pulling creates conflict and everything breaks when pulled too far in too many directions.

This leads me to my final comment: maybe we can just work for someone else. If the job sucks and our lives are miserable, we can just work for someone else and maybe find that one great job that is more aligned with the way we want to live.