![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.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
Two words. Blue Frog.
There's an AWful lot to learn.
no subject
no subject
no subject
no subject
no subject
no subject
Too bad I probably couldn't contract you for the UI part of my research assistantship. Although, if you don't mind, when I have questions here or there I may pick your brain. I know a lot from the ergonomics side, not so much from the coding side. :-)
no subject
no subject
As an aside, I know Avid (the company that bought my former employer) still maintains a large Mountain View engineering team. According to the Avid web site, the only SW or HW position listed today is an FPGA designer, but I know they do drivers and other embedded stuff - you might check 'em out and put up your resume. They're a much better company than my former employer. :-)
no subject
Yeah, I just went to visit the Avid site and they list no software positions, at least in Mountain View. Ah well. One would hope they'd at least want tools - but maybe they don't do that in MV or are already full up.
no subject
no subject
Sounds like a good company!
no subject
no subject
no subject
no subject
no subject
We have a UI group dedicated to fighting the forces of evil, aka, our current UI. If you are interested, send email to me (my user name at livejournal works if you don't know it off the top of your head) and I'll give you the company name and website.
no subject
no subject
no subject
no subject
Our QA manager lives in Livermore and telecommutes two or three days a week, but he's just that good -- the CEO tolerates it because it's preferable to finding someone else.
no subject
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.
no subject
no subject
no subject
I've gotten a lot of job leads from craigslist and kitlist.
I also have a bunch of email from recruiters and such that I could forward to you. There are a couple that seem to be a bit better than others. If you want me to forward you such mail send me a not to lrc at red4est.
no subject
I hadn't tried craigslist yet - thanks! I had been perusing monster. Yikes, that's badly organized.
Will drop you a note. Better than others would be a bit of a relief.
no subject
BTW, it's Saturday -- that's when even working people are supposed to rest ;-) .
no subject
Hee! I promise I'm doing a lot of goofing off. I've read two junk books already today!
no subject
The biggest growth areas here are Web and mobile UIs. You would have no trouble finding a job implementing UIs on the Web, especially the richer, more interactive sites that require more programming clue. Mobile is a smaller market, but growing, no question about it.
I can't speak with authority about mobile anything, but here are some Web technologies you may want to learn:
* HTML/CSS/Javascript. You know about HTML; CSS is layout and presentation rules, and Javascript is code. Put them all together and add asynchronous client/server communication, and you get AJAX ("asynchronous Javascript and XML"). Huuuuuge buzzword these days. :-) AJAX is the tech that Gmail, Google Maps, Flickr, etc. are built on, and though it's messy and hackish, one can build some nice UIs with it.
* Flash/SVG/Flex. This is Macromedia's path to building functional UIs on the Web. Flash is the vector-graphics player everyone knows about, SVG is code, and Flex is a full-fledged UI system based on those. Not as hot a market as AJAX at the moment, but impressive tech nonetheless. A programmer friend of mine is building a "big app" with Flex, and he loves it to pieces.
Of course, backend programming for the Web is done in an entirely different set of technologies: classic C/C++, perl, Java, PHP (sorta frontend too), databases, Python, Ruby, etc. Lots to learn! Whee! :-)
I currently build desktop UIs in Java Swing. It's okay as it goes -- decent language, a fairly mature UI toolkit, and marketable to an extent, but Swing programmers aren't in nearly as much demand as Web people, AFAIK. Check the listings in your area and see what you find.
I can type, really
So THAT'S what AJAX means! One puzzle demystified!
If I were to pick up, say, Javascript, CSS, and PHP, then I could be somewhat employable as a Web UI person, yes? Given I already have a fair bit of HTML and C/C++/Perl/Java. Three big pieces seems like a lot, but I do have a little time. If I start playing with them soon...
I've seen a few job listings for Swing here. I've also seen -- man, there's one I'd REALLY want to put you in. That's the one
Re: I can type, really
For a quick dive into AJAX stuff, you might take a look at openlayers.org (open source project run by a coworker, to produce a common toolkit for ajax mapping apps - if nothing else, it's a fair place to see what all of the issues are.) You definitely need javascript and CSS to be able to do useful stuff with AJAX, but there's not much depth to either of them, just icky special cases - and, well, you handled Motif and traversal, these should be *easy* :-)
oh yeah - 37signals just put up a ruby-on-rails job board - no idea how it's going, but if you want to look in that space as part of picking up a new language (rails has some helper tools that make writing ajax apps easier - or rather, makes writing certain kinds trivial so everyone just writes those :-) it might be worth a glance.
Re: I can type, really
but there's not much depth to either of them
Ah, thanks. I had that impression (particularly about CSS: all icky special cases) but it's good to hear a second opinion.
no subject
no subject
no subject
And by the way, thank you for being someone who gives a shit about documentation! It's so important to get it right. Plus, I've found that in most of the places I've worked, my best sounding boards and allies are people who do documentation and training -- they see the UI from the user's point of view better than anyone else in the organization.
no subject
my best sounding boards and allies are people who do documentation and training
Absolutely. Similarly, the documentation folks I've worked with recently have been able to tell me when an API published by our OS is b0rked, either directly ("Are you sure...?") or indirectly (a page of total confusion where the doc should be).
no subject
Hm, I know a project that needs a bunch of that done... it's too bad that we don't have any money at the moment. And that you're on the wrong coast.
One unusual trait I have among engineers is that I give a shit about documentation: accuracy, appearance, completeness, etc.
Yeah, too many of us don't, at least to a first degree. I give a shit about the fact that we don't give a shit, for what little that's worth. :-) It sucks that documentation and doc people don't get more respect. I worked with one doc guy once who really deserved it... knew his stuff, and wasn't afraid to dig into code to figure out what we'd done when we didn't do a good job telling him, and he'd come bug us about it for details.
I also know a doc person who was told to stop bugging the programmers at a previous job; she pretty much had to play with whatever software they gave her to figure out what they'd changed, and what new buttons or menu items did. And hope that the product they shipped actually matched what she'd been given to document.
Doesn't sound like a great option, unless you find one of those unusual places where they actually care...
Spam-killing
Definitely worthwhile, and it could be fun if you get to learn a bunch of new techniques. Quite a bit of competition, I imagine, including from the free stuff like spamassassin and crm114.
no subject
Hey, where are you these days, anyway? I lost track after the whole Red Hat thing and your transition to MIT. You still there?
My recent employer has the best doc person I've worked with, and I firmly believe she's that good because she bugs the programmers until she has what she needs. No other way she's going to get it, after all.
The more I think about it the more I like the spam filtering idea.
no subject
Spam filtering has got a lot of interesting possibilities. I think maybe the toughest problem is dealing with spammers who are making a point of trying to get around your tool, and probably have more processing power to throw at the problem than your individual customers, unless you can do some interesting p2p thing for sharing data or something... and p2p networks have a whole bunch of other interesting things going on....
no subject
You're absolutely right that spam will be a losing battle. I suspect it *always* will, at least until the rules change drastically (eg charging a fraction of a penny for every mail sent, or some other landscape-altering thing). That sense of "always on the losing end" may be a morale-killer. Not sure.
no subject
no subject
no subject
no subject
1. adding to whoever mentioned voice over IP: phone stuff in
general. Lots of jobs related to one-or-another sort of
phone stuff (or "voice" stuff..... hard to tell where the
line is as to what is "phone".)
2. agree that doc people don't usually get to have much
say. Ditto QA. Some exceptions, but they are exceptions.
3. regarding "Given my motivation, possibly embedded OS work is too far removed from the customer." -- very good point.
I like looking at BAjobs.com because it gives the EMPLOYER'S
job listing page. Places like monster often don't tell you
who the company is or even what SORT of thing they make.
I care about this. I care about what kind of software it
is, what it does, whether they make anything I consider
even vaguely useful, whether the software is something I
can "relate to" (if so the job is "easier") and so on.
It is very slow (compared to say, monster) to look
at one company at a time, but big advantage is that there
is some context about the job.
http://www.bajobs.com/BrowseList.aspx
4. I liked reading your thoughts about tech writing.
I have sometimes thought of tech writing (for myself), but
really haven't pursued the idea, as experience generally
counts MUCH more than aptitude. (I'd think we would both
do fine on aptitude for it.)
I've stayed with what I have a track record for. Call it
practical or call it lazy or whatever.
Good luck, of course.
no subject
2. Yeah, that's definitely my experience in QA, and lots of acquaintances say the same about both QA and docs.
3. Cool! Thanks for the pointer!
4. Hey, lazy's just the sneering word for practical. I like practical. And I sure do know what you mean about experience versus aptitude...
Thanks!