![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
A big whole bunch of ideas, not even exhaustive! Feedback on any of them is very welcome. New ideas to add to the list are also very welcome. Job offers are greeted with an angel choir soundtrack and my frantic stammerings of lifelong gratitude.
1. Embedded OS/driver stuff - My resume screams "embedded OS/drivers". That's my most recent experience, a fair bit of it.
Sadly, what this past job has taught me is I no do drivers. Sadly, most anyone who wants OSes wants a lot of driver/firmware work. Can I find OS work without getting THAT far into the hardware? And can I find it near where I live? Alameda is out, so no Wind River.
Given my motivation, possibly embedded OS work is too far removed from the customer. I can't point to anyone whose life is noticeably better because I fixed a timer bug.
I don't know the internals of any big existing OS because we've always written our own. I know zip about Linux internals, for example. Of course, a lot of Linux work out there would likely be porting, which would put me right back in driver land, so that's probably not great.
Who's doing active OS kernel/internals development?
2. UI design and implementation - Another thing my resume has a big pile of is UI design and implementation. I've got a good decade of that.
Sadly, all of it was in X11/Xt/Motif, and no one uses that any more. I'd need to learn... what? MFC? ASP.NET? Java Swing? Plus, it's hard to find employers who respect good UI design skills. Mostly they respect knowledge of the library you're using. Too bad that's the part I don't have. Can I get it? Quickly? My Xt experience will speed up the learning curve.
Motivation is strong here. I know people who use whatever I write will have an easier time of it if I do my job well.
If I choose this path, which UI package should I learn?
3. Tools - One last bit of experience: I wrote some good-sized chunks of a debugger once.
That sort of thing motivates me if I think of the customer as my coworker down the hall. Other random development tools, ditto.
Pretending to be a compiler person is like pretending to be a physician. That's out. But other tools, I can likely do. So: custom debuggers for custom systems. Simulators, probably. With some learning curve, maybe profiling, or join a team doing static analysis. What else is out there in tools-land? What weird development worlds need weird tools written?
4. Spam-killing - No experience there. It sure does pass the "is it worth doing" test for me. What would I need to learn?
5. Apps destined for non-computer-professionals (software for small businesses, etc) - What's out there? Some of this would be way cool to do.
6. Webby stuff a company deploys for its customers to use - Some of this could be cool too. The debug cycle has got to be frustrating as all get-out, and that's something I've got years of tips and tricks for from my X11 work and embedded work.
7. Other - Any other development ideas?
8. QA - Getting farther off the obvious path, how about QA? It likely won't pay what development pays, but I've done it before and I seem to have the mindset.
9. Documentation - At all possible? I have zero training and zero experience, but it appeals, and I believe I could write clearly about complicated things. One unusual trait I have among engineers is that I give a shit about documentation: accuracy, appearance, completeness, etc. I don't even know what I'd have to learn though.
10. Build/release stuff - I've done this as secondary duties; think of the customer as the team down the hall. Again, likely lower pay than development, but if I'm good I can turn a painful process into something almost pleasant.
11. Other Other - What else? Any other ideas?
1. Embedded OS/driver stuff - My resume screams "embedded OS/drivers". That's my most recent experience, a fair bit of it.
Sadly, what this past job has taught me is I no do drivers. Sadly, most anyone who wants OSes wants a lot of driver/firmware work. Can I find OS work without getting THAT far into the hardware? And can I find it near where I live? Alameda is out, so no Wind River.
Given my motivation, possibly embedded OS work is too far removed from the customer. I can't point to anyone whose life is noticeably better because I fixed a timer bug.
I don't know the internals of any big existing OS because we've always written our own. I know zip about Linux internals, for example. Of course, a lot of Linux work out there would likely be porting, which would put me right back in driver land, so that's probably not great.
Who's doing active OS kernel/internals development?
2. UI design and implementation - Another thing my resume has a big pile of is UI design and implementation. I've got a good decade of that.
Sadly, all of it was in X11/Xt/Motif, and no one uses that any more. I'd need to learn... what? MFC? ASP.NET? Java Swing? Plus, it's hard to find employers who respect good UI design skills. Mostly they respect knowledge of the library you're using. Too bad that's the part I don't have. Can I get it? Quickly? My Xt experience will speed up the learning curve.
Motivation is strong here. I know people who use whatever I write will have an easier time of it if I do my job well.
If I choose this path, which UI package should I learn?
3. Tools - One last bit of experience: I wrote some good-sized chunks of a debugger once.
That sort of thing motivates me if I think of the customer as my coworker down the hall. Other random development tools, ditto.
Pretending to be a compiler person is like pretending to be a physician. That's out. But other tools, I can likely do. So: custom debuggers for custom systems. Simulators, probably. With some learning curve, maybe profiling, or join a team doing static analysis. What else is out there in tools-land? What weird development worlds need weird tools written?
4. Spam-killing - No experience there. It sure does pass the "is it worth doing" test for me. What would I need to learn?
5. Apps destined for non-computer-professionals (software for small businesses, etc) - What's out there? Some of this would be way cool to do.
6. Webby stuff a company deploys for its customers to use - Some of this could be cool too. The debug cycle has got to be frustrating as all get-out, and that's something I've got years of tips and tricks for from my X11 work and embedded work.
7. Other - Any other development ideas?
8. QA - Getting farther off the obvious path, how about QA? It likely won't pay what development pays, but I've done it before and I seem to have the mindset.
9. Documentation - At all possible? I have zero training and zero experience, but it appeals, and I believe I could write clearly about complicated things. One unusual trait I have among engineers is that I give a shit about documentation: accuracy, appearance, completeness, etc. I don't even know what I'd have to learn though.
10. Build/release stuff - I've done this as secondary duties; think of the customer as the team down the hall. Again, likely lower pay than development, but if I'm good I can turn a painful process into something almost pleasant.
11. Other Other - What else? Any other ideas?
no subject
Good things about McAfee are that we're helping the good guys stop viruses, spam, and other nastiness, and it's a pretty good place to work (I've been there for five years). Bad things... well, it's a medium-size corporation, there's corporate politics and stupid management decisions to cope with.
Most of the products I work on these days are written in Java, or a mix of Java and C++, and have browser-based UIs. The most important UI technologies in my area are HTTP, HTML, JavaScript, CSS, and JSP or ASP. Other products, developed elsewhere in the company, use different technologies, but in my area the browser is really taking over as far as new UI development goes. People like being able to access a security product's UI from wherever they are rather than having to go to the computer where the product is installed or install some kind of remote console.
If you're particularly interested in spam-killing you should research mail-based technologies (SMTP, IMAP, Exchange Server, etc.) because most of the coding is in getting the information about the mail and taking appropriate action. Much of what we do involves hooking into the file system, mail server, etc. and intercepting the files/messages as they are stored -- before they can do any damage.
I don't know that I'd recommend changing to documentation as a career for you. It would be a substantial pay cut, and documentation writers don't get a lot of respect. Even though the documentation writers are often in the best position to know what would make the product more or less usable, they are rarely in the best position to make their opinions stick. I was a tech writer for 15 years, and switched to development because I wanted a chance to fix the UI problems I saw rather than just explain how to work around them.
no subject
Thanks also for the list of topics to go look at. Some of those are not going to be hard to learn, and once I pick a direction it'll be good to have smaller things to get started on right away. Then I can tackle the bigger ones over time. That's very useful.
I think I know what you mean, sadly, about documentation people not being heard. My recent employer has one of the best I've ever met, a doc writer who sits in on technical meetings and actively bugs engineers for explanations, and still people don't seem to pay attention. I don't understand why. If it frustrates me when I'm a developer I can only imagine how buggy I'd be if I were the one doing the docs.