OT: Frustated hiring here

[blahblahblah]

The deal is, coincidently we both need folks who can do things (yesterday)…Not someone who is going to screw around for the next 4-5 months “figuring things out from scratch”….Perhaps we’re both being harsh, but we’re like dude, if you really want to do this, couldn’t you have possibly tried to learn this during the past 1-2 years when you already thought your existing skillset needed to be expanded. Why are you going to do this on our dime?

That’s what your company gets for not hiring the best 2-3 software and hardware engineers right out of college every year and then helping them grow in a rewarding career. Had your company been doing this all along you would have a rich, diverse staff of software and hardware engineers able to tackle any challenge.

That’s actually the way things used to work until the MBAs took over. As soon as that chain of new talent coming in was broken, all was lost. The older high-paid guys got laid off as their work was sent overseas, and a lot of the kids entering college realized that engineering was a sucker’s game and all went for law, medicine, or biochem instead. Now those MBA-run shops are screwed, always trying to find that one engineer that has every single buzzword of the day on his resume and bitching on websites like this one that they can’t find one and that all American engineers are lazy and don’t want to learn new stuff.

And as another poster here pointed out, no employer will consider experience done at home in a hobby as real experience. They want you to have done exactly the same thing that they are doing, never mind the fact that that implies that they aren’t doing anything new. But of course most MBAs can’t think that far ahead…

But yes, your last line is right on the money. Try to get your company hiring a couple of sharp grads every year, take care of them and allow them to grow and your company will be in good shape down the road. But then again what company thinks farther ahead than the next quarter anymore?

[sdcellar]

Okay, let’s clarify a few things about emulators, the first of which is any phone that’s worth developing for has an emulator that you can be very productive with. If it doesn’t, you better build one for yourself. (and, btw, flu, a developer capable of such would best fill your needs). An emulator is at least capable of getting you productive for the platform (which is also the question at hand). If you were doing production code, would you want to get things onto a real phone, you bet.

With regard to hardware dependencies, it all depends if you’re writing driver/API code. If you’re developing an app on top of that (which most folks are), you can make a ton of progress with an emulator. And, in many cases, you better be if the hardware implementation doesn’t exist yet. If, instead, you’re the driver/API guy, you still have to consider the emulator, just from a different perspective.

Finally, and this last bit is important, the best developers won’t make poor assumptions based on how things work in an emulated environment. Rather, their assumptions are based on their knowledge and experience with embedded platforms that, while closer to desktops than ever, still have important considerations regarding resource limitations. That is, folks who just might recall what it was like to deal with a megabyte of memory and slow storage mediums are much less likely to embark down a dead end road. This notion doesn’t apply, of course, to things like pixel madness in bad emulators, but does apply to things like, well, reading every damn file on a device when you mean to display information about eight or so (or indexed information is required or whatever). Heck, the bigger mistake people make here is not considering scale in the first place. E.g. it works on the emulator, it works on the phone. It just works like crap when somebody who’s thinking puts 5000 contacts in it.

[sdcellar]

Okay, let’s clarify a few things about emulators, the first of which is any phone that’s worth developing for has an emulator that you can be very productive with. If it doesn’t, you better build one for yourself. (and, btw, flu, a developer capable of such would best fill your needs). An emulator is at least capable of getting you productive for the platform (which is also the question at hand). If you were doing production code, would you want to get things onto a real phone, you bet.

With regard to hardware dependencies, it all depends if you’re writing driver/API code. If you’re developing an app on top of that (which most folks are), you can make a ton of progress with an emulator. And, in many cases, you better be if the hardware implementation doesn’t exist yet. If, instead, you’re the driver/API guy, you still have to consider the emulator, just from a different perspective.

Finally, and this last bit is important, the best developers won’t make poor assumptions based on how things work in an emulated environment. Rather, their assumptions are based on their knowledge and experience with embedded platforms that, while closer to desktops than ever, still have important considerations regarding resource limitations. That is, folks who just might recall what it was like to deal with a megabyte of memory and slow storage mediums are much less likely to embark down a dead end road. This notion doesn’t apply, of course, to things like pixel madness in bad emulators, but does apply to things like, well, reading every damn file on a device when you mean to display information about eight or so (or indexed information is required or whatever). Heck, the bigger mistake people make here is not considering scale in the first place. E.g. it works on the emulator, it works on the phone. It just works like crap when somebody who’s thinking puts 5000 contacts in it.

[sdcellar]

Okay, let’s clarify a few things about emulators, the first of which is any phone that’s worth developing for has an emulator that you can be very productive with. If it doesn’t, you better build one for yourself. (and, btw, flu, a developer capable of such would best fill your needs). An emulator is at least capable of getting you productive for the platform (which is also the question at hand). If you were doing production code, would you want to get things onto a real phone, you bet.

With regard to hardware dependencies, it all depends if you’re writing driver/API code. If you’re developing an app on top of that (which most folks are), you can make a ton of progress with an emulator. And, in many cases, you better be if the hardware implementation doesn’t exist yet. If, instead, you’re the driver/API guy, you still have to consider the emulator, just from a different perspective.

Finally, and this last bit is important, the best developers won’t make poor assumptions based on how things work in an emulated environment. Rather, their assumptions are based on their knowledge and experience with embedded platforms that, while closer to desktops than ever, still have important considerations regarding resource limitations. That is, folks who just might recall what it was like to deal with a megabyte of memory and slow storage mediums are much less likely to embark down a dead end road. This notion doesn’t apply, of course, to things like pixel madness in bad emulators, but does apply to things like, well, reading every damn file on a device when you mean to display information about eight or so (or indexed information is required or whatever). Heck, the bigger mistake people make here is not considering scale in the first place. E.g. it works on the emulator, it works on the phone. It just works like crap when somebody who’s thinking puts 5000 contacts in it.

[sdcellar]

Okay, let’s clarify a few things about emulators, the first of which is any phone that’s worth developing for has an emulator that you can be very productive with. If it doesn’t, you better build one for yourself. (and, btw, flu, a developer capable of such would best fill your needs). An emulator is at least capable of getting you productive for the platform (which is also the question at hand). If you were doing production code, would you want to get things onto a real phone, you bet.

With regard to hardware dependencies, it all depends if you’re writing driver/API code. If you’re developing an app on top of that (which most folks are), you can make a ton of progress with an emulator. And, in many cases, you better be if the hardware implementation doesn’t exist yet. If, instead, you’re the driver/API guy, you still have to consider the emulator, just from a different perspective.

Finally, and this last bit is important, the best developers won’t make poor assumptions based on how things work in an emulated environment. Rather, their assumptions are based on their knowledge and experience with embedded platforms that, while closer to desktops than ever, still have important considerations regarding resource limitations. That is, folks who just might recall what it was like to deal with a megabyte of memory and slow storage mediums are much less likely to embark down a dead end road. This notion doesn’t apply, of course, to things like pixel madness in bad emulators, but does apply to things like, well, reading every damn file on a device when you mean to display information about eight or so (or indexed information is required or whatever). Heck, the bigger mistake people make here is not considering scale in the first place. E.g. it works on the emulator, it works on the phone. It just works like crap when somebody who’s thinking puts 5000 contacts in it.

[sdcellar]

Okay, let’s clarify a few things about emulators, the first of which is any phone that’s worth developing for has an emulator that you can be very productive with. If it doesn’t, you better build one for yourself. (and, btw, flu, a developer capable of such would best fill your needs). An emulator is at least capable of getting you productive for the platform (which is also the question at hand). If you were doing production code, would you want to get things onto a real phone, you bet.

With regard to hardware dependencies, it all depends if you’re writing driver/API code. If you’re developing an app on top of that (which most folks are), you can make a ton of progress with an emulator. And, in many cases, you better be if the hardware implementation doesn’t exist yet. If, instead, you’re the driver/API guy, you still have to consider the emulator, just from a different perspective.

Finally, and this last bit is important, the best developers won’t make poor assumptions based on how things work in an emulated environment. Rather, their assumptions are based on their knowledge and experience with embedded platforms that, while closer to desktops than ever, still have important considerations regarding resource limitations. That is, folks who just might recall what it was like to deal with a megabyte of memory and slow storage mediums are much less likely to embark down a dead end road. This notion doesn’t apply, of course, to things like pixel madness in bad emulators, but does apply to things like, well, reading every damn file on a device when you mean to display information about eight or so (or indexed information is required or whatever). Heck, the bigger mistake people make here is not considering scale in the first place. E.g. it works on the emulator, it works on the phone. It just works like crap when somebody who’s thinking puts 5000 contacts in it.

[an]

sdcellar, you crack me up, thanks for the good laugh. I guess most of the major OEM phone manufacturers don’t make phones that’s worth developing for.

[an]

sdcellar, you crack me up, thanks for the good laugh. I guess most of the major OEM phone manufacturers don’t make phones that’s worth developing for.

[an]

sdcellar, you crack me up, thanks for the good laugh. I guess most of the major OEM phone manufacturers don’t make phones that’s worth developing for.

[an]

sdcellar, you crack me up, thanks for the good laugh. I guess most of the major OEM phone manufacturers don’t make phones that’s worth developing for.

[an]

sdcellar, you crack me up, thanks for the good laugh. I guess most of the major OEM phone manufacturers don’t make phones that’s worth developing for.

[sdcellar]

Not apps, my friend, not apps. And that includes the built-in apps as well.

It’ll pay the bills, but the iPhone and Blackberry pretty much ate everybody else’s lunch. Most apps on other phones are just noise. If you’re lucky, you’re working on something that competes with those (Palm Pre comes to mind). If not, you better send your resume over to flu.

[sdcellar]

Not apps, my friend, not apps. And that includes the built-in apps as well.

It’ll pay the bills, but the iPhone and Blackberry pretty much ate everybody else’s lunch. Most apps on other phones are just noise. If you’re lucky, you’re working on something that competes with those (Palm Pre comes to mind). If not, you better send your resume over to flu.

[sdcellar]

Not apps, my friend, not apps. And that includes the built-in apps as well.

It’ll pay the bills, but the iPhone and Blackberry pretty much ate everybody else’s lunch. Most apps on other phones are just noise. If you’re lucky, you’re working on something that competes with those (Palm Pre comes to mind). If not, you better send your resume over to flu.

[sdcellar]

Not apps, my friend, not apps. And that includes the built-in apps as well.

It’ll pay the bills, but the iPhone and Blackberry pretty much ate everybody else’s lunch. Most apps on other phones are just noise. If you’re lucky, you’re working on something that competes with those (Palm Pre comes to mind). If not, you better send your resume over to flu.

[Author]

Posts