I read two blogs asking whether we are engineers or developers. Their argument is that computer science does not produce engineers because we don't have hard and fast rules for what optimally solves a given problem. Engineers, to them, are people that really deal with the physical laws of the universe when producing a given object in a predictable, mathematically provable way. They have interesting points:

1. Jeremiah Clark, “Jeremiah Clark's Blog : Are Software Developers Really Engineers?,” http://blogs.msdn.com/miah/archive/2009/02/08/are-software-developers-really-engineers.aspx.

2. Scott Palmateer, “Software Alchemy - Scott Palmateer,” http://scottpalmateer.spaces.live.com/Blog/cns%21144A1BAAB1016256%21491.entry.

First, there is plenty of engineering in software development. We don't always see it, especially when we are working within generic frameworks, because the execution behavior of the framework changes the execution behavior of our code and thus removes one of the tenants of good engineering: predictability. Predictability in the physical world is being able to determine the crisis point of a given object well ahead of the crisis occurring. We can predictably tell exactly how much weight a given box made from a given material can contain before it bursts. In fact, you can look at the bottom of most generic brown card board boxes and see the burst point clearly labeled on the Box Manufacturer's Certificate by some box standards organization. Software development often doesn't have that level of predictability as the developer moves further away from the raw hardware.

A current Java based web application running Seam (Richfaces, JSF, EJB 3, JPA/Hibernate and more) on JBoss has very little predictability in my opinion. I believe this to be true because I watch how much injected and generated code is created as my application runs. I can watch my call stack grow as the injected and proxied objects get generated that manage a single request's life cycle to get to my first bean, let alone drill all the way down to my SQL server. I cannot predict exactly how much code will execute between the servlet that is actually processing the incoming request to my bean and I have no idea how long it will take to execute that code. I am left with the hope that it will perform well and that my code will execute in the way I had expected.

There is a concept called "programming by contract" and another "programming by coincidence". Programming by contract says that someone writes a rigid specification for a given API and I write my client code using only the specification as my guide. It also means that the results of any call have been laid out in the specification such that I can trust that with good data the API will respond with a valid result and with bad data that the API will return a specific error response. Programming by coincidence is when you call an API method and set a breakpoint on the line, examine the results and write the rest of the code to handle that response. The problem is that many specifications are either inaccurate or wrong so you end up having to write some measure of code that relies on programming by coincidence. Programming by coincidence almost always eliminates predictability because the behavior of the API or framework is not guaranteed and thus not predictable.

Predictability increases as you move closer to the hardware. You know precisely, or pretty accurately, what your low level language is going to load in order to execute your application and the overhead of those components. The fewer and lighter the external components are, the more likely you can reliably predict performance and side-effect impact. Higher level languages, like Java with some frameworks, don't have the same level of predictability because you can't always tell what the application is really going to load and how those components will effect your application until you start running it.

Note: I love Java as a development language and I couldn't accomplish a giant web application in a timely fashion if I wasn't using some kind of framework. I know though, from a purely scientific perspective, that the more I bring in from the framework, the more risk I take on that the component will not execute or perform to expectations.

Second, software development is about applying design and implementation principals to a specific situation and those principals may not work in other similar situations. MBA students talk about case studies where a professor presents either a real or fictitious scenario to help students to understand a decision making process. The professor may go through several different case studies that may have similar scenarios and vary enough to result in different outcomes. We have the same kinds of problems where one variation in the goals of the project can change components and the project's schedule.

Let's say you have to write a log file reader to extract all the SQL queries generated by Hibernate for two different companies. Company A wants the reader to run though at least 10,000 lines per second and Company B wants 5,000 lines. Company A wants to see the changes in real time and B wants to run through the log at the end of the day and produce a single report. So far both companies could probably be served by the same application. Company A says it wants to store all the output in a database, Company B wants it in memory. Finally Company B says it wants to support IBatis queries and to filter out certain queries. Now we have some design differences that may be significant.

We can see that the reading and translation of the queries is largely the same until Company B wanted to support more than one ORM. One design may take a polymorphic stance and try to generate objects that specifically read each kind of line. Another possible design is one where there is simply a branching statement that just runs the translation code without using a specific object for the kind of log statement. The storage mechanism may require something innovative to get the database updates to meet its performance needs while Company B may require something far more simple. You want to reuse as much code as possible, so how do you do it?

You have a lot of different options and any one of them is probably just fine. You may even decide that your hourly rate is greater than the cost of using something prepackaged so you just buy that application, configure it and then work on something else. You may also sit around and write something in python, perl, Java, C++ or any one of your favorite languages. Tell the same scenario to another developer and he may come back with an entirely different approach and it still meets the same requirements. One approach will be better than another in some respect but may fail in others, thus software becomes a negotiation process in dealing with the trade offs to accomplish the goals set by the customer.

Third, it's a job title damn it! So one company calls you a software engineer and another calls you a software developer and you think it matters? You write designs and implement code in the same way in both places. I write web applications all day and I argue that we mostly find ways to integrate components and systems together to build interesting apps. There's hardly any really innovative code beyond just making the web application work. I half expect to be retitled from Web Architect to Web Cobbler. I could probably resole your shoes while I'm at it.

Job titles are pretty nutty when you really look at them. One company's Software Engineer 4 is another company's junior software engineer. I know this from experience in that one previous employer ranked employees in pay bands so a software engineer made X dollars which caused him to be in the fourth pay band so I was a Software Engineer 4 even though it was an entry level job. My Magic Missile improved remarkably when I became a Software Engineer 5.

You see Principal and Principle Software Developer/Engineer on the job boards all the time. One means that your a very senior engineer and the other means you have a good moral compass. My favorite job title was a guy from Sun that was known as a Computational Theologist.

You have to look at the job responsibilities to understand whether the title is meaningful.

Now I'm not saying to ignore job titles when looking for a gig. Job titles actually domatter though some employers and pundits say it shouldn't. A senior job title should mean senior responsibilities. The title opens doors later in your career and we shouldn't discount titles as a result, especially when they show a track record of increasing responsibilities. That means your employers trust you to lead or do important things and future employers will like that.

Sometimes we get the chance to change a title to something goofy or funny. Grand Coder, Debugger Extraordinaire, "He that lurks within the kernel", Jackass, Meat Calculator, Chief Computer Scientist and so on may sound great but are probably less advisable if you want people to quickly understand what your last job was without having to go into obnoxious detail. While I chuckle that I'm a software cobbler, I won't be changing my title any time soon.

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.

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.

A forty hour work week is 2080 hours of work per year or 260 8-hour days. A fifty hour work week is 2600 hours of work per year or 325 8-hour days. A sixty hour work week is 3120 hours of work per year or 390 8-hour days. Working 8 hours a day, seven days a week is 56 hours of work per week or 2912 hours per year.

There are about 8765 hours in a year according to Google. Sleeping the average 7.5 hours of sleep per night takes 2737.5 hours per year.

The forty hour work week leaves a person with 3947 hours of time remaining for other activities. The fifty and sixty hour guys have 3427.5 and 2907.5 hours of time remaining, respectively. That's almost 10, 9 and 8 hours of free time per day, respectively.

When the hours are typed out in that way it would seem as though one could easily balance work and life into neat boxes on a Gantt chart. A block for 7.5 hours is allocated to sleep, 10 hours to non-income generating activities and the remaining 6.5 hours are all about work. To be clear, that last bit assumes that you work 7 days a week 6.5 hours per day, weekends are simply removed from the equation entirely.

Let's consider that same Gantt chart with weekends. The hours become 37.5 for sleeping in a 5 day work week, 40 hours of work in a week, and 48 hours for the weekend leaving 42.5 hours of free time in the work week or 8.5 hours of free time per day. The fifty hour guy has 6.5 hours of free time per work day and the 60 hour guy has 4.5 hours of free time per work day.

"Free time" is a loaded term, it really means non-income generating time. Out of that time comes activities like eating, bathing, cleaning, commuting, shopping, kids (if you have them), other maintenance activities and recreation.

Now these stats may sound a little unlikely: how many software engineers really work more than 50 hours a week? Well, according to the Bureau of Labor Statics, a branch of the U.S Department of Labor, 17% of software engineers in 2006 were putting in more than 50 hours per week.

There is a famous survey from 1996 of lawyers that asked whether the surveyed attorney would take a 10% pay cut in return for 10% more free time. Attorneys can have incredibly busy lives depending upon the kind of law that they are trying to focus upon. A 50 or 60 hour week can be very reasonable and in fact 37% do. But how many would trade the long hours for less pay? 84.2% of attorneys in one survey would love to slash their pay in favor of more time off.

One aspect of software development, especially early in one’s career, is to work a lot of hours on a lot of projects to get exposure to as many technologies, algorithms, design patterns and styles of software development. All this exposure in the early years can be beneficial in a similar way as an attorney or a doctor being packed full of information during their job’s rights of passage. We have no more or less a difficult and thought requiring job, though we usually can’t account deaths to our mistakes.

There is a point of diminishing returns though. How long before a new developer starts to build the same components over and over again? EJB’s are an example of a technology that nearly every Java developer has implemented a few times and then understands the underlying issues and difficulties. Are you going to learn very many new insights if you keep writing dozens more? Does the work stop being one of new learning and become rote repetition?

It is entirely possible to get a 40 hour work week but it usually comes with a price. Bigger companies and non-profits often require fewer hours than small companies and startups. The downside is that there is far more bureaucracy, slower schedules and sometimes less innovation. On the other hand, there is a push for greater software correctness, design and process. Startups are often not so good on the design and process side of things because they are in a rush to get their product out the door so they can have income. That is only my opinion on design and process, though I’m pretty sure I could find a survey to back that up.

Bigger companies do not necessarily pay any better or worse than other companies, however, their option packages are generally small and irrelevant. Big companies are often public companies too, but a public company can only sell shares at a small discount or hand out a relatively small number of options. The difference is that they are worth something, but the likelihood of becoming a millionaire at a public company as an engineer is pretty slim.

A startup may give a pretty sizable number of shares to its early employees which results in a chance at making a pile of money. The downside is that it is very likely that the options will be worthless as only a very small number of startups go public or are bought out at a profit.

Option packages and employee stock option programs (ESOP) at big companies are usually a good deal. An ESOP is usually discounted so you buy at say 10 to 15 percent below market value, which means you can often flip the stocks, rather than hold them, and get a great return on your investment.

There is an important distinction though between big companies and small companies for senior developers. Big companies can afford to pay well beyond small companies for senior developers. By senior, I mean developers with more than 15 years of development. These developers often top-out the salary range in small companies, while large companies may have significantly larger salary caps.

Salaries alone do not motivate developers, project complexity and responsibilities are often very important for attracting developers. That’s obvious though, pay a creative person a lot of money to do a boring and repetitive task and he’ll still quit. It is simply a matter of time. Give that same developer an interesting job and he will quit too, but he may stick around for years.

Free time comes into play when a developer reaches a point in his life when he is happy to trade salary for free time. Going to a big company or a non-profit may result in an initially lower pay level but much more free time than the average startup. The questions are where are you in your career and how important is it to be able to other things than work?

Some developers look down on these conversations, and interestingly enough, so did the partners of various law firms mentioned in the survey. The complaint is that good lawyers have to love the work and so they want to put in the extra hours. This is what separates the average lawyer from the great lawyers, accord to some of the partners. It’s the level of commitment, not necessarily the actual contribution or quality of work that mattered.

I think we see something similar in the software engineering. There is a “keeping up with the Joneses” attitude related to hours worked. “Land of the overworked and tired” talks about a situation in DC during the summer in which office workers all were dressing up for work because everyone else was doing it. The unspoken communal rule was to dress up and so everyone did it.

We see this in our own work places too. Hours-worked is a great example where people put in really long hours because everyone else is doing it. The problem is that quality of work and start time can become irrelevant in measuring how good of an employee you actually are. Consider that a developer shows up at 6 in the morning and leaves every day at 4. He’s been at the office for 10 hours. Compare him to the developer working from 10 until 7. The other developer has been at the office for 9 hours. A great manager will see the difference and acknowledge that the early morning fellow is really putting in the hours. A mediocre manager may miss that entirely and see the developer working into the evening as the more committed.

However, it is unclear who is actually more productive. It could be that the person with the shorter workday is producing more bug free code than the person putting in the additional hours. It could be argued that a person working long hours is not working as efficiently as a person working shorter hours. It could also be that the longer hours person has been assigned much more work. It could be that the longer hour person is goofing off more or less than anyone else. It’s not possible to tell which is the better employee from hours worked at all. It’s a bad metric.

An argument for working longer hours is to get a promotion, better projects, learn something new, avoid some other activity, get ahead of schedule and as an attempt at getting more salary. The positive is that you may be more productive and making a valuable contribution to the company. It’s really important to love the work and derive real pleasure from it such that the work is its own reward. The negative is that people may not notice or care and thus the positive feedback and esteem that you were hoping for may not occur.

There is a risk that once you work so many hours voluntarily that it can become an expectation. Consider that if you work a 55 hour week every week that eventually your task assignments shape themselves around that schedule. Let’s say that you always get 40 hours of task assignments but work 55 hours. You exceed expectations by accomplishing an additional 15 hours of work on your own initiative and applauded for it. The problem occurs when you are tasked 55 hours of work the following week. At that point you have a new bar to reach each week. Others may still receive 40 hours worth of work though. Now your longer hours are expected but no one else is working as hard as you. Your peers are working 28% less than you and you are getting paid the same as if you were working 40 hours. In theory, the company may reward you for your efforts at review time.

Small companies generally require more hours than larger companies as mentioned a dozen or so times so far. You get better pay depending upon how far the company has come and you may work on something really interesting. The issue of making more money is that it often comes with some kind of externally driven status. You get a slightly neater watch or an expensive car. You get to save more money or have a snazzy couch. The time you are expected to work could easily be 50 hours a week but most companies still go into crunch. How long that crunch lasts for is important.

A crunch in a small company may mean working the 8, 9, 10 or 14 hours a day for 5,6 or 7 days a week. Compare that to a crunch at a company that requires only 40 hours a week. There may very well be a serious issue with ordering people to work the really long hours at a big company. They may raise the hours to 50 or 60 hours too but you started at a much lower number of scheduled hours per week.

In the small company we had a person doing the 2600 hours a year and then working more hours because of a crunch. In the big company, we talked about a person working 2080 hours a year and then raising because of a crunch. No matter how you slice it, the person at the 40 hour a week job is still working fewer hours generally and so has more free time.

There is this steady drive to make more and more money and the easiest way to accomplish that is to hitch up to a small company and work the additional hours. At some point you can look at the salary and ask whether they are paying so much because you are an incredibly skilled developer or because they are compensating you for the additional hours.

There is a moment when your life turns and you realize that you have missed too may weekends, summers, seasons and years. That the big money stops being so worth while and that all you really want is to spend some time barbecuing with family and friends. At that point, maybe it’s time to take fewer hours for less salary and do what so many attorneys wish for.

A friend was talking to me about his job and how things are progressing. Rather, not progressing. Things haven't changed in terms of investments, staffing, customers nor product roadmap development. The company is trudging forward with no real worries of succeeding or failing but certainly not growing and no apparent idea where it is going.

I grinned at his story and asked whether the founders had made it big on a previous startup, were independently wealthy, were investing significantly in the company, had taken no outside money and were acting as the CEO or some other C-level position. He had a look of surprise and answered that all of it was true. Lifestyle companies almost always have very little growth and do it with the founders' own money. My friend is a little bored and worried that things will never get off the ground. His worries are very reasonable too.

Being in a lifestyle company can be great during certain times of your life. There is absolutely nothing wrong with going to a lifestyle company provided that the company is profitable to the point where it is self-sustaining or has slight growth. Negative growth (AKA decline) can be dangerous for any company depending upon the wealth of its founders, the income from their other investments and their willingness to write checks.

Founders create lifestyle companies to have work that matches their lifestyle. Yes, sometimes the obvious is true! These companies are not reserved for the uber-rich trying to avoid boredom. A friend of the family runs a boat engine repair shop where he works about 4 hours a day. He owns his house through inheritance, makes very little money and he's a little too happy about life. He earns below the US poverty line but his house is paid for so he can live cheap and happy.

Lifestyle software companies are fascinating as they are often started by people who have previously made it big, or huge, and have limited motivation to do it again beyond to show that they can or to have something to do. Wealth doesn't make a person happy or busy. So they start a new company and try to make a go of it.

Boredom after huge wealth sounds crazy. It would seem like you could travel all the time, play golf, go back to school or blow stuff up on your new island. How could you be bored with all those new opportunities to goof off? Being independently wealthy may mean that you are making around $120,000 gross on your investments per year, which is obviously enough for most of us to retire on, but it isn’t enough to go on a spending spree since you may still have a mortgage, kids in school or college, all the old bills and you have new costs, like health insurance. Most of the time we hear about the people that make it huge, but there are plenty of people that suddenly find themselves with $3 or $4 million in the bank after a good exit. They have enough money to quit but maybe not enough income to do all the whacky stuff.

Let’s say that you make it moderately big and have $10 million in the bank. You have very few financial concerns at this point beyond being pretty well diversified, which someone is probably managing for you anyway. You are squarely looking at the problem of avoiding boredom. I think everyone agrees that it is a great problem to have. You may goof off for a year or so and then simply be bored and need something interesting to do every day that actually matters. Your job mattered before and now you have to do something that matters again. Finding ways to goof off is not usually a good strategy for finding a new purpose in life. Especially when most of our lives are guided by some kind of work.

As mentioned earlier, a founder may start a company just to avoid boredom but may not want to have the enormous workload they had in the startup that made them wealthy.

Some founders create a lifestyle company where the staff shares some measure of the lifestyle: the staff comes in, does some work, plays some ping-pong or darts, does some more work and then goes home. Other companies are about the founder, which means that the founder has a great life and the staff works pretty hard. However, lifestyle companies usually don't have a lot of growth. Growth means lots of work, lots of difficult challenges and stress. The former situation means that everyone enjoys the rewards of a highly successful individual while the latter means that the staff works hard, but with limited hope of significant gain that would come with a traditional startup or small company.

Startups and small companies usually have a goal or an exit planned since the inception. They know where they want to go though they may not know how to get there. Its normal not to know how to get there and to change directions along the way too. Lifestyle companies usually don't have a clear goal or make little effort to attain those goals.

I used to work in an incubator type space that had cube walls separating companies of 3 to 10 employees. It was nearly impossible to tune out the conversations from the other startups. I was parked next to a lifestyle company and I was often mind-boggled by it. First, I couldn't figure out why anyone would bother paying or even using their service. This thought is common though since many startups are doing something bleeding edge and so it is hard to judge the merit of something until it is deeply explained or adopted by the world. You may even be scratching your head about why anyone would use the product your own company produces.

Second, every Friday, at around 4:30, the founder would come over to his staff and tell them about his plans for the weekend, talk about the Mercedes and how it was failing to meet expectations for some trivial reason and then assign three more hours of work that needed to be ready Monday morning. Third, their customer base only grew in the single digits on a monthly basis. Fourth, he spent most of his time writing travel blogs, which was completely unrelated to his line of business. Fifth, he left early very often while the staff worked late.

This is an example of a lifestyle company which is about the founder. The staff works very hard while the founder is goofing off. The founder has a hobby and you get to work on it with little hope of a big pay-out at the end. What is worse is that you are at risk that the founder will become bored and want a new hobby.

Another company was built around some really good software development tools founded by some guys who had made a lot of money on a previous venture. The company had excellent engineers and they worked on difficult problems and played a lot of Guitar Hero. They may work a 40 or a 50 hour week depending upon needs, but often it was left to the developer how many hours he worked. They weren't making very much money but they were doing something difficult and interesting. The staff and founders alike were happy and the staff had a good stake in the equity of the company. The company goes on and on doing development work but has limited motivation to make it big, so it doesn’t. So it cruises forward on the strength of the founders investments and again has no clear exit or plan to become more than a lifestyle company.

The underlying problem with both kinds of lifestyle companies mentioned here is that they are more like hobbies than actual businesses. The founders needed a way to keep from being bored and so they founded something. One company worked on challenging problems while the other was just challenging. Whether either company will be successful is hard to say since the metrics are different. The founders may be perfectly satisfied with how things are going. The staff could look back on it is a happy time too.

Let's say you are interviewing at a lifestyle company and you know its a good one. You may ask yourself if it is wise to take the job? Non-lifestyle companies have goals and set expectations and you have to meet them. You are measured, challenged and groomed for later positions in and out of the company. Startups are often like pressure-cookers and force you to learn and do so much more in a short period that you grow professionally very quickly. Lifestyle companies may not be so driven and so your career or skills, like the company, may stagnate. It falls on your shoulders to grow for you to continue to succeed beyond the current job. Good and bad lifestyle companies can put you in a position where the technological world passes you by.

Good lifestyle companies can be incredibly good for your quality of life though. Let's say that you came out of a couple of really brutal startups and you are wound-up and tired. That euphoric kind of feeling where you feel a sense of urgency all the time even when there is nothing to do. It comes from always worrying about the next demo, the stability of a server, the scalability of the last commit and that the new feature has a couple of embarrassing bugs in it that will cause a conversation with the dev manager. Living with those thoughts for a few months or years is going to make you a little tense. A good lifestyle company can ease you back to a point where you can enjoy living rather than just working. They are the rest and relaxation job that you may need after a gut-wrenching personal event or overly stressful gig. Think of it as therapy.

The next issue is knowing when to leave. A lifestyle company may pay less than a startup it also may be less challenging and eventually boring. Too easy a job will cause your skills to atrophy and make it terribly hard to get a good job in the future. Further, if the founders get bored or lose too much money then they may close up shop. At some point you'll have to leave, just be sure to leave on your terms.

I often read blogs that have tips for interviewing candidates. I’m always looking for questions that may give me some real deep insight as to what the person is like to work with. It is also important to ask a potential employer about life at the company but I see only a few blogs about the subject. Today I’m writing a little about what to ask the startup type company to see if it is a good company for you to work at.

Take a look at the article “Startups Must Hire the Right People and Watch Every Penny. Or Fail.” and “How to save money running a startup.” Item 11 in the latter article is the most important thing to pay attention to. Then read the comments and see how many people agree with his sentiments. The specific item is that an employer should fire employees that don’t love their work or aren’t committed enough. Now, in all fairness, this was his attempt at clarification but it really doesn’t make things better.

The need for interviewing your employer is growing more critical as beliefs like these continue to gain traction. There is a world of entrepreneurs out there that would work 24/7 and they expect you to be just as committed as they are. Commitment comes in different flavors, some entrepreneurs want you just to focus, be enthusiastic, creative, happy and bring your “A” game every day. Others expect commitment in the form of hours: the more you work, the more committed you are.

Most tech entrepreneurs in major hubs like Boston, the valley, Seattle, Chicago, etc have to work incredibly long hours because there are countless meetings and presentations to make to customers, investors and the industry community at large. The last group is really important because it leads to introductions to even more customers, investors and a wider audience of the industry community. It gets very exhausting and the pace never lets up. The key point to understand is that every aspect of your entrepreneurial life revolves around work and it seeps into every interaction outside of work too.

Some entrepreneurs believe that they are not asking any more of their staff then what he is willing to do himself. This is a scary statement because the entrepreneur is probably working upwards of 70 hours a week anyway. A developer can work that many hours, but we usually see the results in the form of frantic and badly written code leading to a worse release. When a developer complains about a 60 hour week the entrepreneur sees it as a lack of commitment though.

Not all entrepreneurs are like this. Many are really great people that inspire a real sense of camaraderie and excellence. They work hard, are honest and they make sure that their staff is happy too. They may need somewhat long hours, but the work is actually rewarding. Further, some of these guys want to help you along later so that you can build your own company in the future.

Figuring out which entrepreneur you are interviewing for is not exactly easy or precise. You may not be able to find out who you are dealing with until the offer comes in either. You can find out a lot though from the staff during the interview. The following is a short list of questions I generally try to ask each of the interviewers.

1. What time do people generally get in?

It’s good to know if you are working with early risers or a company with specific start of day times. Some companies have very flexible schedules with core hours. Some startups actually run a 9-6 shop in terrible commuter locations.

2. What would you say your daily routine is like?

You could find out that the team likes to grab a coffee at the starbucks around the corner and go over the plans for the day. You could also find out that everyone reports to their desk and reads emails quietly.

3. What is the release schedule like?

Is it a web service that goes through weekly or monthly releases? Is it every 6 months? A year? 2 years? The shorter the window the more you generally have to do. Different project management, QA and development strategies are used for different intervals and kinds of applications.

4. What is your project management style: waterfall, agile or something else?

You know which of these you like and are willing to try.

5. Where do you live?

This sounds really odd, but how far everyone is driving matters. Does everyone live in town while you are going to have to drive an hour? It changes the amount of time you can spend at work and with your colleagues outside. You may find yourself at a place that expects you to work really long hours and then you have a long commute to face while everyone else is close by. They may not understand that you just can’t work the really long hours because of the commute. Another factor is the after hours commitment. Some companies have an active social life and a long commute may make it difficult to join in.

6. Where do people go for lunch?

What you are trying to find out is if people go out for lunch as a group. If you aren’t making much money but everyone goes out then you may have to go out to be accepted in the group. That could be really expensive. It could also be that everyone brings lunch from home and eats at their desk. It could also be that people don’t go out as a group ever.

At some point be sure to get a cup of water or coffee and visit the restroom. This sounds kind of odd, but you really need to see how these people live. You should see if they have an open-office plan and if everyone is silent or talking. Is the “kitchen” a nasty pit or really clean and the same for the bathroom.

These last items may not make sense and may sound dumb. Open-office plans can be noisy or silent except for the clicking of keys. Noisy places mean people are talking to each other while a quiet office can mean that there is nothing to say or everyone knows what needs to be done. A silent office can also mean that people are messaging each other instead of talking. One style or the other does not make it a bad place to work, but you need to sort of know whether you like quiet or noisy places. You also have to be sure that you can live with the total lack of privacy.

A kitchen and a bathroom tells you what the people are like and if there is a cleaning service. I personally like being someplace clean. It matters, I’m a germaphobe. Let’s say that you see an adequate kitchen with the usual things except for tables. Where do people eat? Do people hang out together during lunch?

You usually don’t have a lot of time to ask all of the questions from each interviewer but be sure to ask at least one common question from each interviewer. It’s important to hear similar answers from each person in regard to the life style of the company. A manager will always try to sell the company, but an engineer may be far more straightforward in his answers. Take some time to think about the mosaic of answers to each of the questions after the interview.

There are no right or wrong answers to the above questions. You may really like a frenetic or a silent workplace. You won’t know about the place until you ask.

The most important person to interview is a senior manager or a founder. You will almost certainly interview with a founder in a startup. The company is small and they are into pretty much everything. This is great because they set the pace of the company. You want to talk to him about everything you can and really know this person. The one thing about them that is certain is that you won’t change the kind of person they are no matter how important you may become. A crazy leader stays a crazy leader for awhile. Its whether he is your kind of crazy.

The compensation conversation is the one to listen to the most. Any discussion about stock options must include the size of the share pool. Founders may know the number off the top of their head. The reason they know the number is that they have a huge portion of the shares and they can calculate their wealth almost instantly in the event of a buyout.

Knowing the share pool size lets you determine whether it is a meaningful number of shares. Let’s say you go to a startup and they make you an offer of 10,000 shares on an unknown pool size. You may want to make a $1MM off the deal in the event of a buyout. That means that your shares have to be worth at least $100 per share to get you to a million. Now, what does the company have to be bought for to get you that money. The pool size helps to tell you that. 10,000 shares of a company with 40MM shares means that the company has to be bought out for at least $4 billion in order for you to get $1MM. Good luck.

There are a bunch of terms like ratchets and multipliers that factor into the valuation of options too. The discussion on these topics is incredibly long, but they are mechanisms to ensure that the investors get a decent return on the investment and risk they are taking. Basically, the investors get paid first and at a premium and you get your share of the remainder. That could mean that the investors take an additional $20MM or more off the top of the deal.

Don’t get me wrong, I love options. Just be sure you understand how much you are getting and set your expectations appropriately. If someone interviewing you says we’re all going to be rich, but sure that “we” means that you have a large number of options too.

Everything I am writing here is about trying to collect information about whether a company is a good pick. Some small companies claim to be startups even though they are pulling in $5MM in revenue and running a 15% profit for the past 5 years. It’s very sexy to be a startup and some startups are similar to a 53 year old woman claiming to be 39. They aren’t a startup but they want to be so badly that they take on the startup-lifestyle.

The issue is that small companies have usually already gone through rounds of investment so the share pool is very large. You have to examine the offer package carefully to see if the commitment necessary for the small company is worth the overall effort when compared to the offer from a real startup. Real startups option packages are often more valuable because the number of shares in the pool is very small. The effect is that you can evaluate if the time you will have to put in is worth the final reward.

No matter which company you ultimately decide to work for, be sure that you have done the due diligence and selected a company that you are going to look forward to going to every day. And if that doesn’t work then find a job that you can tolerate. And if that doesn’t work then you probably are better off where you are right now. But no matter what you choose, be sure to find out what you are committing to and who you’ll be working for.