OT: Frustated hiring here

[meadandale]

[quote=sdcellar][quote=meadandale]Don’t get me wrong, I’m always learning a few new things here and there (I read alot) but going full bore into doing phone development on a new platform requires an investment in equipment (you need at least one phone to develop to) and quite a bit of time.[/quote]A real handset, er phone, is nice at some point, but the majority of your work can (and should) be done with an emulator.

[edit]Never mind. Just read your follow-up post on emulators, and yeah, a real phone is key at some point.[/edit][/quote]

I did quite a bit of work on sony ericsson handsets with J2ME…and you only found out about the device idiosyncrasies when you put the phone on the actual device; the emulators would run the app fine.

I’m talking screen resolution, UI widget placement, color, memory…everything looks slightly different when it is on an actual phone. A real device has to be part of your development loop because if you wait until you are about to release to just ‘check it out on a real phone’ it will be the last time you ever make that decision 😉

Not to mention that some phone’s have firmware bugs (this was very common in the J2ME space where each phone would have a hand rolled JRE) that you’d never find on the emulator..only when your app was running in QA…

[AK]

One more positive DISincentive to picking up new stuff on the side … most employers don’t count your knowledge as “real” unless it’s been used on “commercial” projects.

Therefore (a) there’s no clear reward for picking up new skills and (b) the temptation exists to load down one’s current projects with irrelevant and sometimes toxic technologies just to add a few more buzzwords to one’s resume.

[AK]

One more positive DISincentive to picking up new stuff on the side … most employers don’t count your knowledge as “real” unless it’s been used on “commercial” projects.

Therefore (a) there’s no clear reward for picking up new skills and (b) the temptation exists to load down one’s current projects with irrelevant and sometimes toxic technologies just to add a few more buzzwords to one’s resume.

[AK]

One more positive DISincentive to picking up new stuff on the side … most employers don’t count your knowledge as “real” unless it’s been used on “commercial” projects.

Therefore (a) there’s no clear reward for picking up new skills and (b) the temptation exists to load down one’s current projects with irrelevant and sometimes toxic technologies just to add a few more buzzwords to one’s resume.

[AK]

One more positive DISincentive to picking up new stuff on the side … most employers don’t count your knowledge as “real” unless it’s been used on “commercial” projects.

Therefore (a) there’s no clear reward for picking up new skills and (b) the temptation exists to load down one’s current projects with irrelevant and sometimes toxic technologies just to add a few more buzzwords to one’s resume.

[AK]

One more positive DISincentive to picking up new stuff on the side … most employers don’t count your knowledge as “real” unless it’s been used on “commercial” projects.

Therefore (a) there’s no clear reward for picking up new skills and (b) the temptation exists to load down one’s current projects with irrelevant and sometimes toxic technologies just to add a few more buzzwords to one’s resume.

[an]

[quote=meadandale][quote=sdcellar][quote=meadandale]Don’t get me wrong, I’m always learning a few new things here and there (I read alot) but going full bore into doing phone development on a new platform requires an investment in equipment (you need at least one phone to develop to) and quite a bit of time.[/quote]A real handset, er phone, is nice at some point, but the majority of your work can (and should) be done with an emulator.

[edit]Never mind. Just read your follow-up post on emulators, and yeah, a real phone is key at some point.[/edit][/quote]

I did quite a bit of work on sony ericsson handsets with J2ME…and you only found out about the device idiosyncrasies when you put the phone on the actual device; the emulators would run the app fine.

I’m talking screen resolution, UI widget placement, color, memory…everything looks slightly different when it is on an actual phone. A real device has to be part of your development loop because if you wait until you are about to release to just ‘check it out on a real phone’ it will be the last time you ever make that decision 😉

Not to mention that some phone’s have firmware bugs (this was very common in the J2ME space where each phone would have a hand rolled JRE) that you’d never find on the emulator..only when your app was running in QA…[/quote]
Not to mention if you actually develop apps that are extremely dependent on hardware, such as the camera or the file system. You can do you basic development on the emulator, but it won’t get you very far. Every camera chip is different, good lucky trying to find emulator for that. Also, your PC is a lot faster than any phones out there and the file system on the phone is much less optimized than the PC. So, everything might work fine on your PC, but when you put it on the phone, you’ll find out quickly that reading a list of 1000s files from the EFS would crash the phone. That alone would change how your UI would look if you designed your UI around the assumption that the phone can queries for 1000s of files from the EFS easily. There are many more examples like these that make you very weary of developing purely on an emulator for a prolong period of time w/out a device. Emulator definitely have its place, but it can never replace a real device for a long period of time. Even though Nokia have the best emulator out of all the OEM (can’t speak for Apple), there were plenty of idiosyncrasies between phone and emulator that noobs would get told, when they said “but it works on the emulator”, that “we sell phones and not emulator”, so always check your cold on a device before check in.

[an]

[quote=meadandale][quote=sdcellar][quote=meadandale]Don’t get me wrong, I’m always learning a few new things here and there (I read alot) but going full bore into doing phone development on a new platform requires an investment in equipment (you need at least one phone to develop to) and quite a bit of time.[/quote]A real handset, er phone, is nice at some point, but the majority of your work can (and should) be done with an emulator.

[edit]Never mind. Just read your follow-up post on emulators, and yeah, a real phone is key at some point.[/edit][/quote]

I did quite a bit of work on sony ericsson handsets with J2ME…and you only found out about the device idiosyncrasies when you put the phone on the actual device; the emulators would run the app fine.

I’m talking screen resolution, UI widget placement, color, memory…everything looks slightly different when it is on an actual phone. A real device has to be part of your development loop because if you wait until you are about to release to just ‘check it out on a real phone’ it will be the last time you ever make that decision 😉

Not to mention that some phone’s have firmware bugs (this was very common in the J2ME space where each phone would have a hand rolled JRE) that you’d never find on the emulator..only when your app was running in QA…[/quote]
Not to mention if you actually develop apps that are extremely dependent on hardware, such as the camera or the file system. You can do you basic development on the emulator, but it won’t get you very far. Every camera chip is different, good lucky trying to find emulator for that. Also, your PC is a lot faster than any phones out there and the file system on the phone is much less optimized than the PC. So, everything might work fine on your PC, but when you put it on the phone, you’ll find out quickly that reading a list of 1000s files from the EFS would crash the phone. That alone would change how your UI would look if you designed your UI around the assumption that the phone can queries for 1000s of files from the EFS easily. There are many more examples like these that make you very weary of developing purely on an emulator for a prolong period of time w/out a device. Emulator definitely have its place, but it can never replace a real device for a long period of time. Even though Nokia have the best emulator out of all the OEM (can’t speak for Apple), there were plenty of idiosyncrasies between phone and emulator that noobs would get told, when they said “but it works on the emulator”, that “we sell phones and not emulator”, so always check your cold on a device before check in.

[an]

[quote=meadandale][quote=sdcellar][quote=meadandale]Don’t get me wrong, I’m always learning a few new things here and there (I read alot) but going full bore into doing phone development on a new platform requires an investment in equipment (you need at least one phone to develop to) and quite a bit of time.[/quote]A real handset, er phone, is nice at some point, but the majority of your work can (and should) be done with an emulator.

[edit]Never mind. Just read your follow-up post on emulators, and yeah, a real phone is key at some point.[/edit][/quote]

I did quite a bit of work on sony ericsson handsets with J2ME…and you only found out about the device idiosyncrasies when you put the phone on the actual device; the emulators would run the app fine.

I’m talking screen resolution, UI widget placement, color, memory…everything looks slightly different when it is on an actual phone. A real device has to be part of your development loop because if you wait until you are about to release to just ‘check it out on a real phone’ it will be the last time you ever make that decision 😉

Not to mention that some phone’s have firmware bugs (this was very common in the J2ME space where each phone would have a hand rolled JRE) that you’d never find on the emulator..only when your app was running in QA…[/quote]
Not to mention if you actually develop apps that are extremely dependent on hardware, such as the camera or the file system. You can do you basic development on the emulator, but it won’t get you very far. Every camera chip is different, good lucky trying to find emulator for that. Also, your PC is a lot faster than any phones out there and the file system on the phone is much less optimized than the PC. So, everything might work fine on your PC, but when you put it on the phone, you’ll find out quickly that reading a list of 1000s files from the EFS would crash the phone. That alone would change how your UI would look if you designed your UI around the assumption that the phone can queries for 1000s of files from the EFS easily. There are many more examples like these that make you very weary of developing purely on an emulator for a prolong period of time w/out a device. Emulator definitely have its place, but it can never replace a real device for a long period of time. Even though Nokia have the best emulator out of all the OEM (can’t speak for Apple), there were plenty of idiosyncrasies between phone and emulator that noobs would get told, when they said “but it works on the emulator”, that “we sell phones and not emulator”, so always check your cold on a device before check in.

[an]

[quote=meadandale][quote=sdcellar][quote=meadandale]Don’t get me wrong, I’m always learning a few new things here and there (I read alot) but going full bore into doing phone development on a new platform requires an investment in equipment (you need at least one phone to develop to) and quite a bit of time.[/quote]A real handset, er phone, is nice at some point, but the majority of your work can (and should) be done with an emulator.

[edit]Never mind. Just read your follow-up post on emulators, and yeah, a real phone is key at some point.[/edit][/quote]

I did quite a bit of work on sony ericsson handsets with J2ME…and you only found out about the device idiosyncrasies when you put the phone on the actual device; the emulators would run the app fine.

I’m talking screen resolution, UI widget placement, color, memory…everything looks slightly different when it is on an actual phone. A real device has to be part of your development loop because if you wait until you are about to release to just ‘check it out on a real phone’ it will be the last time you ever make that decision 😉

Not to mention that some phone’s have firmware bugs (this was very common in the J2ME space where each phone would have a hand rolled JRE) that you’d never find on the emulator..only when your app was running in QA…[/quote]
Not to mention if you actually develop apps that are extremely dependent on hardware, such as the camera or the file system. You can do you basic development on the emulator, but it won’t get you very far. Every camera chip is different, good lucky trying to find emulator for that. Also, your PC is a lot faster than any phones out there and the file system on the phone is much less optimized than the PC. So, everything might work fine on your PC, but when you put it on the phone, you’ll find out quickly that reading a list of 1000s files from the EFS would crash the phone. That alone would change how your UI would look if you designed your UI around the assumption that the phone can queries for 1000s of files from the EFS easily. There are many more examples like these that make you very weary of developing purely on an emulator for a prolong period of time w/out a device. Emulator definitely have its place, but it can never replace a real device for a long period of time. Even though Nokia have the best emulator out of all the OEM (can’t speak for Apple), there were plenty of idiosyncrasies between phone and emulator that noobs would get told, when they said “but it works on the emulator”, that “we sell phones and not emulator”, so always check your cold on a device before check in.

[an]

[quote=meadandale][quote=sdcellar][quote=meadandale]Don’t get me wrong, I’m always learning a few new things here and there (I read alot) but going full bore into doing phone development on a new platform requires an investment in equipment (you need at least one phone to develop to) and quite a bit of time.[/quote]A real handset, er phone, is nice at some point, but the majority of your work can (and should) be done with an emulator.

[edit]Never mind. Just read your follow-up post on emulators, and yeah, a real phone is key at some point.[/edit][/quote]

I did quite a bit of work on sony ericsson handsets with J2ME…and you only found out about the device idiosyncrasies when you put the phone on the actual device; the emulators would run the app fine.

I’m talking screen resolution, UI widget placement, color, memory…everything looks slightly different when it is on an actual phone. A real device has to be part of your development loop because if you wait until you are about to release to just ‘check it out on a real phone’ it will be the last time you ever make that decision 😉

Not to mention that some phone’s have firmware bugs (this was very common in the J2ME space where each phone would have a hand rolled JRE) that you’d never find on the emulator..only when your app was running in QA…[/quote]
Not to mention if you actually develop apps that are extremely dependent on hardware, such as the camera or the file system. You can do you basic development on the emulator, but it won’t get you very far. Every camera chip is different, good lucky trying to find emulator for that. Also, your PC is a lot faster than any phones out there and the file system on the phone is much less optimized than the PC. So, everything might work fine on your PC, but when you put it on the phone, you’ll find out quickly that reading a list of 1000s files from the EFS would crash the phone. That alone would change how your UI would look if you designed your UI around the assumption that the phone can queries for 1000s of files from the EFS easily. There are many more examples like these that make you very weary of developing purely on an emulator for a prolong period of time w/out a device. Emulator definitely have its place, but it can never replace a real device for a long period of time. Even though Nokia have the best emulator out of all the OEM (can’t speak for Apple), there were plenty of idiosyncrasies between phone and emulator that noobs would get told, when they said “but it works on the emulator”, that “we sell phones and not emulator”, so always check your cold on a device before check in.

[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?

[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?

[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?

[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?

[Author]

Posts