Is Finding Part Time Work In IT Unrealistic?

I like my current job writes "Having worked full-time in IT for the past 12 years, I would really like to work less and focus on other goals and priorities in my life. I asked my current employer and was shot down. It seems like everyone I know in IT works full-time except for entry-level help desk staff. Striking out on my own seems to be the only way to control the ball and chain around my ankle. However, my experience with independent consulting is a 'feast or famine' situation, with work coming all at once, thus making part-time impossible, or the other extreme (which is even more likely). Is part-time work a pipe dream in IT? Maybe a career in toilet cleaning is calling me."

Comments

The Boss Decides... so be the Boss

[alain94040]

One reason corporations don't like part-time is that as long as you are full-time, you actually tend to work way past 40 hours a week. You do whatever it takes to get the job done, under impossible deadlines.

Once you are part-time, you start saying no to crazy demands. Corporations just hate that.

My answer? Be your own boss. It comes with a caveat: starting your own business alone is a bad idea. Guess what? It takes more than one person to provide something of value. It doesn't take an army of hundreds, but a small dedicated group of friends can do amazing things. The sum really is larger than the parts.

Take a look at fairsoftware.net. It was designed for exactly that purpose: geeks starting a side business together.

Re:The Boss Decides... so be the Boss

[plover]

There's always a catch.

I have several friends who have tried this over the years, and know other people who have tried this. The bottom line is: friendships can fail under the strain of a business relationship, and when the friendship fails, the business is not far behind. My wife has worked for three of these ventures over the last 15 years, where two friends created a business, had a falling out, and the business collapsed as a result. All three times. In none of those cases were the owners able to remain friends. She is now with a family owned business who are having their own difficulties right now, but there's no risk of a partnership collapsing here to accelerate it.

Being in it with a friend at a stressful time, when you have one idea about how to save the company, and your friend has a different-and-incompatible idea, and there's just enough money left to try one of your ideas, that's a pressure cooker not many relationships can survive.

Now, you may have a "less permanent" idea about business. Maybe you just want to start a company for the purpose of working, but don't care if it stays together longer than three years or so. As long as you and your partners agree up front, that may work for you.

One other piece of advice -- hire an independent person to do the books, someone you both can trust. Not just an external accountant, but a bookkeeper who sees the day-to-day spending, and lets you both know that the other isn't spending money foolishly.

I will say that family owned businesses seem to be the exception to the rule, as long as Dad or Mom or Grandpa is the "boss" and everyone else understands that.

Re:The Boss Decides... so be the Boss

[Jeff DeMaagd]

My answer? Be your own boss. It comes with a caveat: starting your own business alone is a bad idea. Guess what? It takes more than one person to provide something of value.

Guess what? That's not absolutely true. It's not hard for one person to provide something of value. You're not going to start a Tesla Motors but if you chose projects and products approprate for a one person operation, you might even do those projects and products better than larger operations could.

I don't know where you think otherwise, but my experience shows such an absolute statement is not true. I'm in business for myself, no partners and no employees. Even before I started it, I knew several people that are in business for themselves, more people than had partnerships or larger businesses. From what I understand, partnerships are generally riskier ventures than sole proprietorships. I think the way to make a business partnership work is to have one person that's actually in control, the other partners are "minor" partners, or hire a non-partner to do the management work.

Re:The Boss Decides... so be the Boss

[mcrbids]

One reason corporations don't like part-time is that as long as you are full-time, you actually tend to work way past 40 hours a week.

Funny. I'm an employer, in a corporation, and I would *never* ask anyone to work over 40, even when on salaried pay.

But I still like full-time over part-time because full time is "immersive" - people who dedicate their time and primary mind share are more productive per time unit. I get more and better work per hour from a full-time engineer than a part-time employee.

My answer? Be your own boss. It comes with a caveat: starting your own business alone is a bad idea. Guess what? It takes more than one person to provide something of value. It doesn't take an army of hundreds, but a small dedicated group of friends can do amazing things. The sum really is larger than the parts.

I call bullshiznt. You think being your own boss means you WON'T work bat-shiat crazy hours under impossible deadlines? BWAH HAW HAW HAW HA!!!!!!

On the right track

[BadAnalogyGuy]

If you are involved in the development of software then you will be on the treadmill. The only way out is to either strike out on your own or to give up on the industry altogether.

Personally, I wouldn't do it. But I can see how leaving the industry completely is attractive for some. Just be prepared for the paycut.

But then again, money isn't everything, and if you can improve your quality of life, even with a paycut, then more power to you.

Re:I did it

[murdocj]

So you were only available 2 days a week, and you're upset that your boss couldn't somehow schedule all of the work to occur those 2 days? You say "he placed another employee to deal with issues that came up while I was out of the office"... what was he supposed to do? Put the problem on hold 4-5 days till you were available?

It's one thing to say "this is my code, my system, no one else touches it without talking to me first" if you are available normal working hours. If you aren't available, guess what, someone else is going to have to deal with the "issues" that come up while you are out of the office. Where I work, people are nervous if there's only one full time employee who understands how to do something, having a part-timer be the only one would be utterly unacceptable, unless the function is pretty marginal to being with.

Re:I did it

[Spazmania]

You misunderstand. I'm suggesting that someone who isn't entry level, someone with real responsibility who tries to drop to part time sets himself up for failure. He's asking the manager he works for to greatly exceed normal and reasonable expectations. Few can.

I will, however, defend my choices this far: I carried a cell phone and left standing instructions to call me when faced with something that genuinely couldn't wait. Knucklehead didn't call. He did wait though: he postponed tasks until I *wasn't* there.

Get the definition right

[heretic108]

In the IT industry as I've known it, 'part time work' is anything less than 80 hours/week.

Re:Get the definition right

[hobo sapiens]

Not sure if you are joking, but if not...then you need a new job. Or you may just need to put your foot down. I have been in IT for years as a web developer for a few diff companies, and have never worked like that. Get your stuff done at work, make it clear you are willing to work a little extra where needed (which should be rare) but if there is bad planning, well, tough. IT shops need to be brought back to reality, namely, that poor planning cannot be overcome by stressing out your workers. And I've done pretty well, and thus far my family hasn't starved. The people who are often overworked are overworked because they let it happen. I have known way too many "heroes" who are all willing to work as long as needed for no good reason at all. Trouble is, today's hero is tomorrow's burnout.

Or become a consultant. You may work the hours, but they are no longer a free gift from you to the company. You bill every hour you work.

Re:Get the definition right

[nabsltd]

Any project that requires "significant overtime" is a project that was planned with unrealistic ideas of how much work would be required.

This assumes the overtime is free because the workers are on salary. If the overtime gets paid (even as normal hours instead of 1.5x), then it's possible the planning took this into account and was just willing to pay the price to get the job done in fewer calendar days.

Otherwise, it's most likely a company with employees who aren't able to get jobs anywhere else, so they can't push back against the unreasonable demands of management.

Re:Get the definition right

[Bodrius]

Trollish ad-hominem apart, the parent AC comment does bring up a valid point.

Web application development does have some characteristics that makes it more natural to do gradual, measured updates that do not 'require significant overtime'.

Part of it may be their current limitations (some things just cannot be done in html+js, and many things should not be done in html+js), but mostly it is just the way the tech is supposed to work by design.

A lot of the time, the 'required significant overtime' in traditional apps is a consequence of the features being tightly coupled - even if not in the code itself, ultimately they tend to be tightly coupled at application delivery. This makes death marches almost unavoidable without very conservative planning, because "it's all or nothing": by the time you 'require' that overtime, removing a feature that is not ready will often look as risky / expensive as trying to complete it. A 'late cut' normally brings in at least binary changes, installer changes, etc that also need to be tested before the whole app is released - and the horrible feeling of waste for everybody involved, because after investing so much the feature missed the boat and now may never even get shipped.

In general, web development doesn't make the app easier to implement in time (sometimes, very much not so) - but it forces a loosely coupled interface for your features:

- Gradual updates are easy to prop to web servers and generally transparent to the users.
- REST architectures help to keep features self-contained (essentially you're updating / publishing a new resource at a url - much of the time you can isolate any code update to just the component that serves that specific url).
- Proper use of CSS and html/code separation mean that fit&finish UI changes, which are often a good share of that overtime, can be updated more dynamically than the application logic.

By design, the web makes it easier for people to 'cut late', and release the 'cut' features a bit later, transparently to the users. Once the penalty for missing the release boat is not fatal to the feature, people are a lot more willing to acknowledge schedule risks, and less willing to try heroics to get their pet feature done in time. Features go back to requiring time, not overtime.

Granted, that doesn't mean there are no death marches in web development shops, there are plenty. Or that traditional apps cannot be architected to use very granular, automatic updates, to deal with the same thing. I'm just saying that the web, by nature, is already architected this way, so it is easier to break away from the implications of a release model that was created when software shipped in little boxes full of floppy disks.

Re:Get the definition right

[hobo sapiens]

Sure, I agree. There is plenty of built in functionality in HTML and CSS to take advantage of.

My rule is if a layer has some built in functionality, don't use another layer to simulate it. Don't use Javascript to style things that CSS can do, don't use CSS to make things that HTML already does (like classing divs to look like h1 elements) and the list goes on.

Depending on the audience and purpose of the site, make your site fail gracefully if the user agent doesn't understand javscript. Case in point, a site I did recently, http://ampedia.redbeartrading.com/ works this way. The menu is a folder tree. If you have javascript + cookies turned on then the site will remember which folders you had open and reopen them for you when you return. If no javascript, then everything will be expanded by default. Sure, you lose the convenience but you can get to the content. If you want convenience stop being a luddite and get a user-agent that does javascript. The markup on that site is semantic, so if your user-agent doesn't understand CSS the info will still be relatively well organized. How is this possible? By using default behaviour for each layer to the extent possible.

An experienced web dev knows how the layers fit together, and that's sort of to my original point: there are lot of layers that you have to know well in order to be a good web developer. HTML and CSS is the foundation of web development. But just as there is more to a house than the foundation, there is much much more to web development.

Re:Maybe it depends on where you are

[dunkelfalke]

that is the main difference between the european and the american attitudes.
americans prefer to work hard, europeans prefer to get things done.