5 ms·

I'll go out on a limb and explain what developers 'feel'. Say that you're comfortable with remote work - In the case of a local employee, I don't want to have

by sp4rki 16y ago

I'll go out on a limb and explain what developers 'feel'. Say that you're comfortable with remote work - In the case of a local employee, I don't want to have to commute 5 days a week, 2 hours to an fro. Sometimes I just don't feel well enough to go to the office, but I'm not as bad as to not work at all. Sometimes I just need a change of scenery. In the case of a international employee, sometimes the best person for the job will not be a local hire. Sometimes it makes more business sense to hire cheaper for a quality employee that doesn't operate out of your immediate area. You can easily fly a developer over for a few days every month or two if you want to discuss things in person, but most of the time a Skype call is more than enough. Be flexible and you'll keep good developers happy enough to go all out and really want to make YOUR product better. Drop the degree requirement - Not sure if you approve or disapprove here, but if you're willing to pay high wages and stake in the company make sure that you're not discriminating on formal education. The moment I find out that I'm being payed less because I don't have a title, instead of it being because of the quality of my work and my experience is the moment I start looking for a new job. In my case, I've never been discriminated based on a diploma, and more often than not I've been payed more than employees with degrees because of proven experience and productivity. Guarantee the job only requires 40 hours per week - Hard work does not mean that I should work 12 hours a day, not even because you pay 'high wages'. You want quality projects? Keep your developers happy. Don't push them to put work over families, social life, or hobbies. Be flexible, specially regarding office hours. Do this and the day you tell them that you just got a retarded deadline pushed a month early, you'll find developers working 80 ~ 100 hours a week to get the project done. You reap what you sow so to speak. Of course, you'll have to be a team player and give them a few weeks off the next week though. Offer to train people in a new language - Offering benefits to further your employees career makes almost any developer a happy camper. Buy them books and send them to conferences. It's an investment that's well worth it. I'm pretty sure you probably agree with this one, but it's important to point it out nonetheless. My point is that if you want great developers to feel at home in your company and help you build a great product, you need to be as flexible and laid back as possible towards your developers without, of course, giving in to mediocrity. You might like employees that work 12 hours a day every day and are always in the office by nine am, but the people you need are the ones that will move your company forward, and more times than not this are the one's that want their employment conditions to be 'fair' and easygoing.

nhangen 16y ago
I'm fine with much of that, but only after someone proves that they deserve it. To me, these seem more like rewards or perks than initial offerings. As an employer, if someone comes in to my office with those requirements, they need to show me that they can produce...otherwise, we're not starting off on the right foot. Can you imagine someone in any other field asking for the same? They would be laughed out of the building. I'm not saying that makes it right or wrong...but it's certainly interesting. I guess my point, and what's most important to me, is not the tally of hours worked, but someone's willingness to buy in to our product, and more importantly, their ability to recognize the difference between getting by and getting things done. Team goes both ways.
- sp4rki 16y ago
  Ahh but those are perks indeed. The thing is, if a developer is mediocre with the perks in place, you take them away. If he's still mediocre, you let him go. He was a mediocre employee however you see it. Here's the catch. To make sure you have an employee that feels empowered, challenged, and engaged you need to offer this perks beforehand. If you don't they're just going to feel as a regular employee. Unimportant and replaceable. Developers don't look at themselves as grunt workers after they've acquired significant experience (enough experience to expect these kind of perks), but as management/executive material who would rather program than do whatever management tasks he'd do if he was a manager. Managers and executives are the dudes that won't get a ton of flak for coming in later in the day or for taking an hour and a half of lunch instead of just one. I'll be honest, I've worked as the general manager of an outsource development company and I found the job generally lackluster and not as challenging as coding, therefore I prefer to code. The fact that I find a general manager's job easier than coding make's me want to have similar perks, and I bet I'm not the only one out there that thinks like this.
- j_baker 16y ago
  That's interesting because I don't put in hard work until my employer proves they deserve it. Someone has to make the first move. Do you see the dilemma here?
  - 16y ago

by sp4rki 16y ago

nhangen 16y ago

I'm fine with much of that, but only after someone proves that they deserve it. To me, these seem more like rewards or perks than initial offerings. As an employer, if someone comes in to my office with those requirements, they need to show me that they can produce...otherwise, we're not starting off on the right foot. Can you imagine someone in any other field asking for the same? They would be laughed out of the building. I'm not saying that makes it right or wrong...but it's certainly interesting. I guess my point, and what's most important to me, is not the tally of hours worked, but someone's willingness to buy in to our product, and more importantly, their ability to recognize the difference between getting by and getting things done. Team goes both ways.

sp4rki 16y ago
Ahh but those are perks indeed. The thing is, if a developer is mediocre with the perks in place, you take them away. If he's still mediocre, you let him go. He was a mediocre employee however you see it. Here's the catch. To make sure you have an employee that feels empowered, challenged, and engaged you need to offer this perks beforehand. If you don't they're just going to feel as a regular employee. Unimportant and replaceable. Developers don't look at themselves as grunt workers after they've acquired significant experience (enough experience to expect these kind of perks), but as management/executive material who would rather program than do whatever management tasks he'd do if he was a manager. Managers and executives are the dudes that won't get a ton of flak for coming in later in the day or for taking an hour and a half of lunch instead of just one. I'll be honest, I've worked as the general manager of an outsource development company and I found the job generally lackluster and not as challenging as coding, therefore I prefer to code. The fact that I find a general manager's job easier than coding make's me want to have similar perks, and I bet I'm not the only one out there that thinks like this.
j_baker 16y ago
That's interesting because I don't put in hard work until my employer proves they deserve it. Someone has to make the first move. Do you see the dilemma here?
- 16y ago