Depending on whether you actually have any authority over the person/people doing the developing you can bill it as architecture experience, lead developer, etc. If you can identify the where and the how and validate that they did it the way you want, the only thing you're skipping is the grunt work. Thats fine, the hard and interesting part of developing is usually the how and why and determining direction anyway.Future proofing!
I posted this in the other thread but I guess it should go here.
We were talking about next-gen stuff and the question came up over who should own the BIOS. As just a single person rummaging through 22k+ source files, I'm constantly bogged down at work. Really we need 4-6 people on this. So we 're going to have someone else write the BIOS in the future. My job will be to look at the code, see what needs to be changed, but instead of changing it I will tell this company exactly what they should change, and when we get the binary back I'll confirm their changes.
Am I wrong in feeling like that's a bit different than what I was hired on as? I feel like I won't grow as a developer AT ALL.
The other side is I will be able to develop open source BIOS as my primary focus, but the scope of work is so large I don't know if a single person can do it.
I don't know if I'd call it authority. Without really getting into too many specifics and being hypothetical - let's say we hire Asus to make our motherboards (we don't). Asus has in-house BIOS/firmware engineers that are working on the same source code that I do (depending on processor, but same base source code). What we'd do is say "Ok Asus, we'll pay you this fee and you'll develop our BIOS." Meanwhile, I have access to the source code, so my job would be to look in the code and say "I think this knob needs to be changed" or whatever, send them an email, and have them do it. Because I have intimate knowledge of the source and how it operates, verifying is easy.Depending on whether you actually have any authority over the person/people doing the developing you can bill it as architecture experience, lead developer, etc. If you can identify the where and the how and validate that they did it the way you want, the only thing you're skipping is the grunt work. Thats fine, the hard and interesting part of developing is usually the how and why and determining direction anyway.
You jest but I swear this is half the bad code I run into.Future proofing!
I agree with Tenks here. It sounds like the company came to their senses but instead of giving you direct help, they're just handing off the work to someone else and asking you to play mall cop.Sounds like your job got offshored Noods
Fuck yeah OPEN SOURCE.It's not decided
I should say - everything is literally just up in the air at this point
Knowing enterprise proprietary code most certainly the latterIts foolish man.
Let's put it in perspective though. Our bios is 22k source files. Core boot is a couple hundred?
What bios do you think is more secure and full featured?