Then would you kindly get your TCL manuals off of it?;)
Seriously, though, I'm amazed how few fellow coders think about this. I mean, it's either your career or (for many in open source) idealogy. It's important stuff. And I wish more would think about it. I've had clients that were honestly surprised that they didn't get the full IP because "that's how the last guy did it." And for small clients, IP is the last thing you want to bring up during contract negotiations. They don't want to have to think about it, and it's awful easy for them to get cold feet at that point. I know that might sound kind of sneaky, but after losing a few contracts for no other reason, you find yourself adapting. Ah, well...capitalism. Love it or starve. *
* Not to be mistaken for an endorsement of our econimic system. I just live here.
I'm kind of spamming this thread, but this is a common misconception that I think is important for us all to be aware of. If you're coding as a contractor in North America, it is not considered a work-for-hire unless you have a contract that explicitly states that it is. That code is a big part of your value as a contractor. Don't be too quick to give it away.
I'm going to be maddeningly self-referential here, but I think you're assuming that you're giving away more than you are. If you're writing code as a contractor (I'm being a bit of geo-bigot here and assuming that you're in north america - don't know enough about anyone else's copyright laws), the copyright is yours, unless your contract states otherwise. If you're an employee, then, yes, it is the company's unless you have an agreement otherwise.
I'm pretty sure that this is what you meant, but just to clarify (under US law at least - it's the same in Canada, but I couldn't find a reference quickly) - if you're an independent contractor, the copyright only belongs to the guy with the cash if it's explicitly stated in the contract that this is a work for hire.
Only certain kinds of work actually qualify as a "work for hire" under the copyright statute. For example, it is a common misconception that software qualifies as a work for hire. It is not, however, one of the enumerated categories of works that qualifies as a work for hire in the copyright statute.
Source
When freelancing, or representing my company, I never assign the copyright to the buyer, unless:
they understand that all code used will be written from scratch,
that this will dramatically increase the development time of the project
that $x is the price if it's not a work for hire, and that $x + $bignum is the price if it is.
Part of what people get when they hire me or my company is a big-ass code library. It's impossible to be competitive these days without that. I'm not about to assign any part of that to someone else, and I'm not going to be giving them copyright on anything I might develop for them without appropriate compensation.
As for the survey, yeah, most of the questions were maddeningly vague. They didn't include most of the copyright situations I've been faced with, including the one where I had an employee contract stating that they could use anything I wrote for them as they saw fit, and so could I.
These things are definitely important. My gripe with Eugenia's reviews is that they're generally just an excuse for her to spout her own (poorly researched, poorly informed) opinions on interface design as if they were God's Own Truth.
I've never complained about slashdot's story posting (hey, I don't have to read the articles), but it does bug me that she keeps getting cred by having her rants posted.
Given the apparent popularity of templating systems for PHP I'm likely in a minority, but I really don't see the point. Languages like perl need some way of getting variables and at least some basic controls structures into the HTML so you don't have to resort to multiple print statements (god, the bad old days...). But PHP does this all on it's own already.
Granted, this is often horribly, horribly abused with all kinds of spaghetti code strewn about the presentation layer, but this is the developer's fault, not that of the language. There's absolutely no reason you can't implement an MVC architecture (or just put your main code somewhere other than your presentation layer) without resorting to a templating engine.
As far as I can tell, the only benefit of PHP templates is that it forces you to keep your code somewhere other than in the presentation. This is offset by generally having the ability to drop out into PHP anywhere you want to in the template anyway. In exchange, you add another layer of complexity to your application, increase execution time, are forced to learn a new syntax and are (frequently) shoehorned into the way the template engine thinks you should structure things.
It's also often mentioned that it's easier on non-coders if you're handing the templates off to someone else for markup. But I really don't understand why (excuse the lack of indintenting - slashdot didn't like it)
{if $user == "admin" } You can {$admin_option} {/if}
is considered more intuitive than:
<?php if ($user_type == "admin"): ?>
You can <?= $admin_option =>
<?php endif; ?>
And if you're going to expose your HTML people to a tiny bit of code, it might as well be the actual language, which they may find useful someday. (Yeah, there's a couple more lines in the PHP example to suit my own formatting tastes).
It seems to me that their only real purpose is to help enforce some kind of coding standards. I prefer to excercise a little discipline on my own. Nothing but variable expansion and control structures go into the presentation layer. The code that does the real work is elsewhere. If I'm overseeing others, I make sure they do the same. And god help them if they use a print statement for anything besides debugging.
(Caching comes up as an advantage on occasion, but there are other options that don't involve marrying yourself to a template engine).
I'll grant that I might be missing something obvious and wonderful. If I am, this is the place it'll be pointed out...
Don't know that I would call it a pattern. My first (succesfully installed) distro was RH 5.2. Debian was the first I tried, and I went back to it very briefly after I'd learned my way around this linux thing a bit. 7.0 was my first Mandrake and I've stuck with it since.
It's not a matter of not liking the command line (although I've only got four terminals open as I'm typing this, and only one instance of vim - it's an admin day), or not liking to tweak things. Linux is my primary workstation. I depend on it to get stuff done, so I don't have the time to fuss with it that I might like. Mandrake Just Working makes it newbie friendly, but it also makes it a dependable working environment. I'm not planning on changing anytime soon.
I think there's a definite market for distributions that are easy to use, easy to maintain, and don't require you to spend a lot of time compiling from source or editing config files. That I can do all that if I want or need to is the icing.
I'm sure we'll see the usual gamut of heavy-handed tactics (as not so long ago seen with 'net radio) from them. From this brief conversation at least some of them seem pretty damned smug. It's a humourous exchange:
Jan: Depending on how you treat your musicians, you may or may not be evil. How do you treat your musicians?
Exec: Well, I think we treat them pretty good.
Jan: Do they make any money?
Exec: Um... well, you know. It varies from contract to contract.
(No affiliation with Magnatune, I just think it's a good idea).
Friends of mine started home-schooling their kid, after some terrible experiences with public schooling at grade 2. She's in grade 8 now. It was a big jump for them, and they were a bit nervous about it, but it's turned out great.
What surprises a lot of people, though, is how well socialized she is. She's gregarious, has friends from many age groups (rather than just those in the same grade she is), participates in lots of group activities (some of them organized with other home-schoolers, some classes like French or Spanish, some just general extra-curricular stuff). She's way more well adjusted than a public school kid like myself was at her age.
She decided she wanted to try public school for a year in grade 6. She stuck it out, but it was a generally negative experience. All it took was a couple of truly evil and ignorant teachers and the general prison-like atmosphere of public school to make her withdrawn and sullen. (She wasn't ready to sign on with a gang or anything, but the change was dramatic, and it took a while for her to regain her naturally more social demeanor). This was in one of the best schools in our city. Scholastically, she's ahead of her grade by a couple years in most subjects (I did some science with her last year, and went through two years of curriculum before hitting stuff she didn't know).
The poor socialization thing, from what I've seen, is pretty much a myth. If the parents are zealots keeping their kid out of school and away from people so they're not exposed to Evil Thoughts, then sure the kids going to be poorly adjusted. In a case like that public school may be their only salvation. But it's only like that if the parents make it that way.
And to keep this sort of on-topic, the internet is an invaluable resource for home schooling. There are a ton of sites dedicated to it, published lesson plans, and there is still the.edu domain out there. I used the internet heavily when putting together science lesson plans.
Zen garden is great, but I think it's still more in the "this is where we can go" category than the "production website" category. You can make a site with all your presentation in CSS, but because of the buggy CSS implementation in some browsers that are still out there (cough*IE5.5) there are some things that you can't reliably do yet. What the site looks like is still the most important thing to a lot of clients out there.
Your best strategy is still to use tables for the broad layout, as much as I hate them, and CSS for all your content markup.
We've been slowly dropping how much presentation is in HTML over the past (too many) years, but in some recent internal proof-of-concept tests that we've done, there were too many restrictions on the design required in order to get things working with what's still out there.
Believe me, I can't wait for the day...maybe in another year or two.
"i" before "e", or fix with "xp". And now you know where I stand on the vi/emacs battle lines. heh.
Our PMs actually are from the trenches, and as we grow I plan to keep it that way. There are two things I want to keep in mind as I figure this out, though. One is that there are always new technologies, and new-to-me technologies. We're in the web applications side of things. I don't know how it compares in terms of speed of emerging technologies to other areas of IT, but from this side of the fence, it seems pretty fast.
The other thing is that if my primary role in a project is managing it, I'm not going to have as much time in the code as the guys actually putting things together. I might know what they're doing, and be able to get up to speed on something fast if I have to, but I have to depend on my people to know details I might be unaware of. I think it's important that I know enough to ask about those details, but they need to know enough to give me answers.
And now, instead of elaborating further, I need to go spend some quality time with a book;).
If you're asking either side "stupid questions", you're bound to lose something in the translation, no?
There can be a real danger there...I guess where I was going with that was that you can't be afraid to ask things that might have a very rudimentary answer. On the technical side, I sometimes find myself asking for clarification on something, even though I understand the technology, to make sure my team and I really are talking about the same thing, and to make sure I'm not missing something critical. One thing I think is important for PMs to recognize is that they're fallible. The technical team is all over this stuff on a daily basis. They're always going to have a deeper understanding of what's going on. On the other hand, you can't get too carried away with this, or they're not going to have time to get any work done.
On the client side, even with the savvy ones, there's often an organizational dissonance on many things - organizations develop their own shorthand for talking about things, and even thought it's bascially the same language, sometimes the dialect is different enough to let a bit of confusion in.
I guess what I'm saying is that when I'm playing PM, I try to be very careful about letting my ego slip in. It's ok if people think you're asking for blindingly obvious answers, as long as you make sure you're getting all the details nailed down.
I help run a much smaller company, and one of my hats is project management. I can't imagine trying to manage a project and not understanding the underlying technology, albeit at a much higher level than those doing the actual work. Our coders are well worth their price, but part of that is because I can ask them stupid questions (I know they're stupid because one of my other hats is coding).
The thing is, I need to be able to ask them stupid questions, ask the client stupid questions, and then synthesize it into something remotely intelligent. I need to keep both parties happy, balance client needs against what's reasonable to ask of my team and take responsibility if it all goes to hell. I need to think of as many things that could go wrong as possible and make sure we have the resources to deal with them if it happens.
If your PMs are just glorified clerks (and I've met enough that are), then they're of no more use than some wizard-reliant VB coder. I hope that I'm at least competent at what I do (we're still in business, anyway), and that I can make our coder's jobs as easy as possible. But I've found that more and more, I view the time I spend coding as relaxation time. There's a lot less stress when all I need to do is make something work.
(And it sounds like your PMs should be fired. Feel like moving into managment?;) ).
Yep, and for help desk support (which this obviously is, despite the long list of "requirements"), that's not bad for these parts. Cost of living is pretty low in Edmonton.
Of course, the list of software they'd like you to be familiar with is huge. But you have to remember that HR people will put everything on the list they could possibly want. It's like contract negotiations - ask for the moon, you might get a microsatelite.
I'll take a wild stab that this is a listing for Convergys. They're a fairly big employer here, actually treat their employees pretty well, and they get paid ok. They're looking for someone that can read through a script, maybe improvise a bit with a few software products, and be good on the phone.
The really funny job postings that I've seen have been things like "Requres n+5 years experience in (insert technology n years old)". I've been tempted to apply for a few of those just for the laugh.
Cool, thanks! That does look like an excellent package. The feature list that AC posted as a response is enough to make me take a serious look at it. Particularly "WAR, JAR and EAR import and export", "Archive Based Deployment" and Jboss support. Handy, indeed.
Thanks for the reply. Refactoring is going to be a major issue on the project I'm looking at (cleaning up offshored code;) ), so knowing that is very helpful. And it's all server-side, so GUIs aren't an issue for me at this point.
I've been a die-hard non-IDE type for a long time, although I like to keep my options open and revisit the state of IDEs fairly often. It's looking like some features of IDEs (managing project files, for example) are going to be helpful enough on this one that I can move away from my beloved vim for some things at least. Although if I can get vim keybindings, too, I'll be really happy. Hell, I have a nasty tendency to send emails that end in:wq.
It looks like I'm going to be getting into the Java game very soon (and really looking forward to it - I've been wanting to find an excuse to put the time into it). I haven't looked at Java IDEs since NetBeans way back (just pre J2EE, if I recall). Anyway, I'm looking for an IDE I can love, having been generally skeptical of them. I've used emacs or vim for almost everything.
What would be ideal is something that plays extra-nice with JBoss and won't get in my way, which is my usual complaint with IDEs. I'm leaning toward Eclipse with the JBoss plugins, but I'm curious to know what others think. Anyone care to recommend their favorite?
I'm a web consultant based in Canada. Our clients tend to be organizations that outsource most of their IT, and we've seen an increase in overseas offshoring, primarily to India, in the last couple of years. Almost without exception the quality of work is awful. Projects are poorly planned and code is indecipherable.
I find it hard to believe that this is because there aren't any good Indian developers. The situation seems to be more reminiscent of the bubble days of the tech economy in North America, when companies were hiring anyone they could get their hands on, and trying to pass them off as savants when they were fresh out of some diploma factory. This wasn't the only reason for the massive collapse, but it seems likely it was a contributing factor.
I expect as the false economy of offshoring is slowly seen for what it is, as poor quality and project failure take their toll, that a similar thing will happen with the tech sectors of these nations. (Likely not as drastic, as there was a nasty combination of things that caused the bust over here).
There's money to be made off the pipe-dreams of starry-eyed PHBs, but there's a price to be paid for fueling their disappointment.
We did what you're doing. The highs are better than you could imagine, the lows much, much worse. You can avoid a lot of the latter by thinking ahead (which it sounds like you're doing, so you're one up on nearly everyone else).
Write a business plan. Possibly hire a consultant to help you with this. It is worth it, and without a good one, you can't get a loan or a line of credit, and just as importantly, you won't know what your goals are.
Have at least six months salary saved away. This is hard, but it will make your life infinitely easier. You will have slow months, and you need to be prepared for it.
Look into incorporation, or some form of limited liability corporation. Benefits of this vary depending on where you are. Consult a lawyer and accountant.
Find your professionals. You will need a lawyer to get you set up as a company and help you write out your contracts. Do not, under any circumstances, skip this step. Contracts are your life blood. Get an accountant. The less accounting you have to do, the more of your work you can do. And he'll do it better.
Market. Contacts are good, but referrals are haphazard at best. You will need to advertise, network and generally get your name out there. If there's just two of you, this will take up a lot of your available resources. Consider hiring someone who does this, or talk to local secondary schools. They'll often have student marketers on the cheap, but be aware that just as your client's get what they pay for, so do you.
Do not undercharge. Do not differentiate yourself based on price. You will not make money by charging less. There are plenty of weekend web slingers with FrontPage to take care of that market. Let them have it. You're a professional - respect yourself enough to bill what your worth. (This sounds very obvious, but it's probably the most common mistake new companies make).
You will work like a dog. I was told this many, many times, but no one told me how hard a dog works. They work hard.
Have an exit strategy. If it all goes to hell, make sure you have a graceful way to get out. You'll need to know at what point you will have to consider the business to have failed, and allow yourself enough time to get back into the workforce.
We took slightly less than half that advice, and we recently celebrated two years on our own. It would have been a lot less stressful if we'd done all of the above. Dogged persistance and being good at what you do will get you a long way, but dogged persistance stops being fun quickly.
Finally, good luck! Despite all the posters telling you not to do it, despite me telling you that you'll work and suffer for years before seeing the big financial payoff, if ever, it's a huge adventure. There's no feeling like knowing you're the one making the decisions, you're the one deciding what the right way to do things is, and knowing that you're the one that will reap the rewards if you pull it off.
You're dead on about problem clients. Some clients are not worth what you'll put into them, even if they're willing to pay a lot to get it. We've turned down clients (or said "no" to existing clients) for many reasons. Sometimes it's because we know that what they want can't be done in a way that will satisfy them, often because they've indicated that they're not willing to pay a price that makes it a worthwhile business proposition, and sometimes just because we know they'll be hell to work with.
That last one seems to often be skipped - if they pay enough, it should be worthwhile. It's not. From a business standpoint, you'll end up putting more into customer care than you can possibly make on the project. From a personal standpoint, they will suck the joy of the business out of you.
More generally, charging too little seems to the single most common mistake new companies (web or not) make. You won't be able to charge as much as the big boys right off, but don't undervalue your talents. You're a professional, with experience in a demanding field. If you try to compete solely on cost, you won't be taken seriously, and you'll run out of money damned fast. Let the FrontPage jockeys compete on price. High quality service has to be paid for.
Slashdot Mirror
Then would you kindly get your TCL manuals off of it? ;)
Seriously, though, I'm amazed how few fellow coders think about this. I mean, it's either your career or (for many in open source) idealogy. It's important stuff. And I wish more would think about it. I've had clients that were honestly surprised that they didn't get the full IP because "that's how the last guy did it." And for small clients, IP is the last thing you want to bring up during contract negotiations. They don't want to have to think about it, and it's awful easy for them to get cold feet at that point. I know that might sound kind of sneaky, but after losing a few contracts for no other reason, you find yourself adapting. Ah, well...capitalism. Love it or starve. *
* Not to be mistaken for an endorsement of our econimic system. I just live here.
I'm kind of spamming this thread, but this is a common misconception that I think is important for us all to be aware of. If you're coding as a contractor in North America, it is not considered a work-for-hire unless you have a contract that explicitly states that it is. That code is a big part of your value as a contractor. Don't be too quick to give it away.
(See my comment here)
I'm going to be maddeningly self-referential here, but I think you're assuming that you're giving away more than you are. If you're writing code as a contractor (I'm being a bit of geo-bigot here and assuming that you're in north america - don't know enough about anyone else's copyright laws), the copyright is yours, unless your contract states otherwise. If you're an employee, then, yes, it is the company's unless you have an agreement otherwise.
I'm pretty sure that this is what you meant, but just to clarify (under US law at least - it's the same in Canada, but I couldn't find a reference quickly) - if you're an independent contractor, the copyright only belongs to the guy with the cash if it's explicitly stated in the contract that this is a work for hire.
When freelancing, or representing my company, I never assign the copyright to the buyer, unless:
Part of what people get when they hire me or my company is a big-ass code library. It's impossible to be competitive these days without that. I'm not about to assign any part of that to someone else, and I'm not going to be giving them copyright on anything I might develop for them without appropriate compensation.
As for the survey, yeah, most of the questions were maddeningly vague. They didn't include most of the copyright situations I've been faced with, including the one where I had an employee contract stating that they could use anything I wrote for them as they saw fit, and so could I.
My cat's free next November...
These things are definitely important. My gripe with Eugenia's reviews is that they're generally just an excuse for her to spout her own (poorly researched, poorly informed) opinions on interface design as if they were God's Own Truth.
I've never complained about slashdot's story posting (hey, I don't have to read the articles), but it does bug me that she keeps getting cred by having her rants posted.
Given the apparent popularity of templating systems for PHP I'm likely in a minority, but I really don't see the point. Languages like perl need some way of getting variables and at least some basic controls structures into the HTML so you don't have to resort to multiple print statements (god, the bad old days...). But PHP does this all on it's own already.
Granted, this is often horribly, horribly abused with all kinds of spaghetti code strewn about the presentation layer, but this is the developer's fault, not that of the language. There's absolutely no reason you can't implement an MVC architecture (or just put your main code somewhere other than your presentation layer) without resorting to a templating engine.
As far as I can tell, the only benefit of PHP templates is that it forces you to keep your code somewhere other than in the presentation. This is offset by generally having the ability to drop out into PHP anywhere you want to in the template anyway. In exchange, you add another layer of complexity to your application, increase execution time, are forced to learn a new syntax and are (frequently) shoehorned into the way the template engine thinks you should structure things.
It's also often mentioned that it's easier on non-coders if you're handing the templates off to someone else for markup. But I really don't understand why (excuse the lack of indintenting - slashdot didn't like it)
is considered more intuitive than:And if you're going to expose your HTML people to a tiny bit of code, it might as well be the actual language, which they may find useful someday. (Yeah, there's a couple more lines in the PHP example to suit my own formatting tastes).
It seems to me that their only real purpose is to help enforce some kind of coding standards. I prefer to excercise a little discipline on my own. Nothing but variable expansion and control structures go into the presentation layer. The code that does the real work is elsewhere. If I'm overseeing others, I make sure they do the same. And god help them if they use a print statement for anything besides debugging.
(Caching comes up as an advantage on occasion, but there are other options that don't involve marrying yourself to a template engine).
I'll grant that I might be missing something obvious and wonderful. If I am, this is the place it'll be pointed out...
Don't know that I would call it a pattern. My first (succesfully installed) distro was RH 5.2. Debian was the first I tried, and I went back to it very briefly after I'd learned my way around this linux thing a bit. 7.0 was my first Mandrake and I've stuck with it since.
It's not a matter of not liking the command line (although I've only got four terminals open as I'm typing this, and only one instance of vim - it's an admin day), or not liking to tweak things. Linux is my primary workstation. I depend on it to get stuff done, so I don't have the time to fuss with it that I might like. Mandrake Just Working makes it newbie friendly, but it also makes it a dependable working environment. I'm not planning on changing anytime soon.
I think there's a definite market for distributions that are easy to use, easy to maintain, and don't require you to spend a lot of time compiling from source or editing config files. That I can do all that if I want or need to is the icing.
I'm sure we'll see the usual gamut of heavy-handed tactics (as not so long ago seen with 'net radio) from them. From this brief conversation at least some of them seem pretty damned smug. It's a humourous exchange:
(No affiliation with Magnatune, I just think it's a good idea).
Friends of mine started home-schooling their kid, after some terrible experiences with public schooling at grade 2. She's in grade 8 now. It was a big jump for them, and they were a bit nervous about it, but it's turned out great.
What surprises a lot of people, though, is how well socialized she is. She's gregarious, has friends from many age groups (rather than just those in the same grade she is), participates in lots of group activities (some of them organized with other home-schoolers, some classes like French or Spanish, some just general extra-curricular stuff). She's way more well adjusted than a public school kid like myself was at her age.
She decided she wanted to try public school for a year in grade 6. She stuck it out, but it was a generally negative experience. All it took was a couple of truly evil and ignorant teachers and the general prison-like atmosphere of public school to make her withdrawn and sullen. (She wasn't ready to sign on with a gang or anything, but the change was dramatic, and it took a while for her to regain her naturally more social demeanor). This was in one of the best schools in our city. Scholastically, she's ahead of her grade by a couple years in most subjects (I did some science with her last year, and went through two years of curriculum before hitting stuff she didn't know).
The poor socialization thing, from what I've seen, is pretty much a myth. If the parents are zealots keeping their kid out of school and away from people so they're not exposed to Evil Thoughts, then sure the kids going to be poorly adjusted. In a case like that public school may be their only salvation. But it's only like that if the parents make it that way.
And to keep this sort of on-topic, the internet is an invaluable resource for home schooling. There are a ton of sites dedicated to it, published lesson plans, and there is still the .edu domain out there. I used the internet heavily when putting together science lesson plans.
Yeah, but it looks like he's right ;)
Zen garden is great, but I think it's still more in the "this is where we can go" category than the "production website" category. You can make a site with all your presentation in CSS, but because of the buggy CSS implementation in some browsers that are still out there (cough*IE5.5) there are some things that you can't reliably do yet. What the site looks like is still the most important thing to a lot of clients out there.
Your best strategy is still to use tables for the broad layout, as much as I hate them, and CSS for all your content markup.
We've been slowly dropping how much presentation is in HTML over the past (too many) years, but in some recent internal proof-of-concept tests that we've done, there were too many restrictions on the design required in order to get things working with what's still out there.
Believe me, I can't wait for the day...maybe in another year or two.
"i" before "e", or fix with "xp". And now you know where I stand on the vi/emacs battle lines. heh.
Our PMs actually are from the trenches, and as we grow I plan to keep it that way. There are two things I want to keep in mind as I figure this out, though. One is that there are always new technologies, and new-to-me technologies. We're in the web applications side of things. I don't know how it compares in terms of speed of emerging technologies to other areas of IT, but from this side of the fence, it seems pretty fast.
The other thing is that if my primary role in a project is managing it, I'm not going to have as much time in the code as the guys actually putting things together. I might know what they're doing, and be able to get up to speed on something fast if I have to, but I have to depend on my people to know details I might be unaware of. I think it's important that I know enough to ask about those details, but they need to know enough to give me answers.
And now, instead of elaborating further, I need to go spend some quality time with a book ;).
I appreciate your thoughtful response, kein.
There can be a real danger there...I guess where I was going with that was that you can't be afraid to ask things that might have a very rudimentary answer. On the technical side, I sometimes find myself asking for clarification on something, even though I understand the technology, to make sure my team and I really are talking about the same thing, and to make sure I'm not missing something critical. One thing I think is important for PMs to recognize is that they're fallible. The technical team is all over this stuff on a daily basis. They're always going to have a deeper understanding of what's going on. On the other hand, you can't get too carried away with this, or they're not going to have time to get any work done.
On the client side, even with the savvy ones, there's often an organizational dissonance on many things - organizations develop their own shorthand for talking about things, and even thought it's bascially the same language, sometimes the dialect is different enough to let a bit of confusion in.
I guess what I'm saying is that when I'm playing PM, I try to be very careful about letting my ego slip in. It's ok if people think you're asking for blindingly obvious answers, as long as you make sure you're getting all the details nailed down.
I help run a much smaller company, and one of my hats is project management. I can't imagine trying to manage a project and not understanding the underlying technology, albeit at a much higher level than those doing the actual work. Our coders are well worth their price, but part of that is because I can ask them stupid questions (I know they're stupid because one of my other hats is coding).
The thing is, I need to be able to ask them stupid questions, ask the client stupid questions, and then synthesize it into something remotely intelligent. I need to keep both parties happy, balance client needs against what's reasonable to ask of my team and take responsibility if it all goes to hell. I need to think of as many things that could go wrong as possible and make sure we have the resources to deal with them if it happens.
If your PMs are just glorified clerks (and I've met enough that are), then they're of no more use than some wizard-reliant VB coder. I hope that I'm at least competent at what I do (we're still in business, anyway), and that I can make our coder's jobs as easy as possible. But I've found that more and more, I view the time I spend coding as relaxation time. There's a lot less stress when all I need to do is make something work.
(And it sounds like your PMs should be fired. Feel like moving into managment? ;) ).
Yep, and for help desk support (which this obviously is, despite the long list of "requirements"), that's not bad for these parts. Cost of living is pretty low in Edmonton.
Of course, the list of software they'd like you to be familiar with is huge. But you have to remember that HR people will put everything on the list they could possibly want. It's like contract negotiations - ask for the moon, you might get a microsatelite.
I'll take a wild stab that this is a listing for Convergys. They're a fairly big employer here, actually treat their employees pretty well, and they get paid ok. They're looking for someone that can read through a script, maybe improvise a bit with a few software products, and be good on the phone.
The really funny job postings that I've seen have been things like "Requres n+5 years experience in (insert technology n years old)". I've been tempted to apply for a few of those just for the laugh.
Cool, thanks! That does look like an excellent package. The feature list that AC posted as a response is enough to make me take a serious look at it. Particularly "WAR, JAR and EAR import and export", "Archive Based Deployment" and Jboss support. Handy, indeed.
Thanks for the reply. Refactoring is going to be a major issue on the project I'm looking at (cleaning up offshored code ;) ), so knowing that is very helpful. And it's all server-side, so GUIs aren't an issue for me at this point.
I've been a die-hard non-IDE type for a long time, although I like to keep my options open and revisit the state of IDEs fairly often. It's looking like some features of IDEs (managing project files, for example) are going to be helpful enough on this one that I can move away from my beloved vim for some things at least. Although if I can get vim keybindings, too, I'll be really happy. Hell, I have a nasty tendency to send emails that end in :wq.
It looks like I'm going to be getting into the Java game very soon (and really looking forward to it - I've been wanting to find an excuse to put the time into it). I haven't looked at Java IDEs since NetBeans way back (just pre J2EE, if I recall). Anyway, I'm looking for an IDE I can love, having been generally skeptical of them. I've used emacs or vim for almost everything.
What would be ideal is something that plays extra-nice with JBoss and won't get in my way, which is my usual complaint with IDEs. I'm leaning toward Eclipse with the JBoss plugins, but I'm curious to know what others think. Anyone care to recommend their favorite?
Yes, now we're into the spurious and fun Windows-bashing. You didn't get the memo?
I'm a web consultant based in Canada. Our clients tend to be organizations that outsource most of their IT, and we've seen an increase in overseas offshoring, primarily to India, in the last couple of years. Almost without exception the quality of work is awful. Projects are poorly planned and code is indecipherable.
I find it hard to believe that this is because there aren't any good Indian developers. The situation seems to be more reminiscent of the bubble days of the tech economy in North America, when companies were hiring anyone they could get their hands on, and trying to pass them off as savants when they were fresh out of some diploma factory. This wasn't the only reason for the massive collapse, but it seems likely it was a contributing factor.
I expect as the false economy of offshoring is slowly seen for what it is, as poor quality and project failure take their toll, that a similar thing will happen with the tech sectors of these nations. (Likely not as drastic, as there was a nasty combination of things that caused the bust over here).
There's money to be made off the pipe-dreams of starry-eyed PHBs, but there's a price to be paid for fueling their disappointment.
Why not? It can already make itself disappear. Give Damian a few months.
What, being Justin Timberlake isn't embarrasing enough?
We did what you're doing. The highs are better than you could imagine, the lows much, much worse. You can avoid a lot of the latter by thinking ahead (which it sounds like you're doing, so you're one up on nearly everyone else).
We took slightly less than half that advice, and we recently celebrated two years on our own. It would have been a lot less stressful if we'd done all of the above. Dogged persistance and being good at what you do will get you a long way, but dogged persistance stops being fun quickly.
Finally, good luck! Despite all the posters telling you not to do it, despite me telling you that you'll work and suffer for years before seeing the big financial payoff, if ever, it's a huge adventure. There's no feeling like knowing you're the one making the decisions, you're the one deciding what the right way to do things is, and knowing that you're the one that will reap the rewards if you pull it off.
You're dead on about problem clients. Some clients are not worth what you'll put into them, even if they're willing to pay a lot to get it. We've turned down clients (or said "no" to existing clients) for many reasons. Sometimes it's because we know that what they want can't be done in a way that will satisfy them, often because they've indicated that they're not willing to pay a price that makes it a worthwhile business proposition, and sometimes just because we know they'll be hell to work with.
That last one seems to often be skipped - if they pay enough, it should be worthwhile. It's not. From a business standpoint, you'll end up putting more into customer care than you can possibly make on the project. From a personal standpoint, they will suck the joy of the business out of you.
More generally, charging too little seems to the single most common mistake new companies (web or not) make. You won't be able to charge as much as the big boys right off, but don't undervalue your talents. You're a professional, with experience in a demanding field. If you try to compete solely on cost, you won't be taken seriously, and you'll run out of money damned fast. Let the FrontPage jockeys compete on price. High quality service has to be paid for.