Forgot your password?
typodupeerror

Comment: Re:Call the boss (Score 1) 441

by ElecCham (#31659320) Attached to: Best Way To Land Entry-Level Job?

I'll actually go one step further on that: make personal connections. Think about anyone you know reasonably well who is in the field. Use them as resources. I got my first programming job via a friend of mine; you may say "nepotism", but think about it this way: if you're gonna hire someone, would you rather have one of your employees vouch for them, or have to rely solely on the impression you've gotten by chatting for an hour or two?

I've recently found myself job-hunting again, for the first time in ten years. While I am indeed going on an interview today, after having been called by a recruiter when he saw my resumé on Dice, I have four strong leads - one of which is for my "dream job" - and all of those came by contacting people I know.

Things I can mention that have worked very well for me:

  • Participate in open-source projects - even just at the bug-fixing level. If you search Google for my name in quotes (and prospective employers will!), nearly every hit on the first four pages is me, despite sharing a name with a NASCAR driver and a judge in a prominent civil-rights case. The majority of those hits are mailing list posts I have made.
  • Go to trade shows, if you can possibly manage it. Some of them offer a reduced rate if you're paying your own way, and obviously some of them (i.e., LinuxTag) are quite affordable (possibly excepting travel!) If you have any idea what you would like to specialize in, this gives you the opportunity to meet the "people behind the code", which - let me tell you - is one of the strongest "ins" that you can hope for.
  • Spend some wetware cycles on software design! I can't tell you how many people I've worked with who are sharp, smart coders... and can't write a clean API to save their life. Hiring managers really, really like this. My recommendation there is - at the risk of "drinking the cool-aid" - going and studying the Qt or KDE source code and design guidelines. Even if you're not intending to be a C++ programmer. I've not looked hard at KDE, but Qt is some of the cleanest code from the standpoint of API design and modularity that I've ever seen. (I'm not necessarily talking about the code inside a module - some of that is pretty grody, but that happens on a project that big.)
  • Lastly, I suggest striking a balance between specialization and still being very flexible. As an example, I worked at Maxtor for many years. When things started getting ugly from the work-environment perspective, I kept talking about leaving. Most people - particularly, say, servo engineers - generally responded with, "Where are you gonna go? Seagate's not hiring." My response was, "Hey, I'm an applications programmer. I don't care what's at the other end of the cable - I don't even care if there is a cable!" Basically, the servo engineers got paid a fair bit more... but I have a much, much easier time finding a job - and have never been laid off, short of the company going under.

Good luck!

Science

Sweet, Sour, Salty, Bitter, Protein ... and Now Fat 210

Posted by timothy
from the visit-the-chiba-clinic-for-an-upgrade dept.
ral writes "The human tongue can taste more than sweet, sour, salty, bitter and protein. Researchers have added fat to that list. Dr. Russell Keast, an exercise and nutrition sciences professor at Deakin University in Melbourne, told Slashfood, 'This makes logical sense. We have sweet to identify carbohydrate/sugars, and umami to identify protein/amino acids, so we could expect a taste to identify the other macronutrient: fat.' In the Deakin study, which appears in the latest issue of the British Journal of Nutrition, Dr. Keast and his team gave a group of 33 people fatty acids found in common foods, mixed in with nonfat milk to disguise the telltale fat texture. All 33 could detect the fatty acids to at least a small degree."

Comment: Documentation - and needing it! (Score 1) 769

by ElecCham (#30312216) Attached to: Is Linux Documentation Lacking?
There are two things, in my experience, that are holding Linux - and indeed, the majority of open-source projects - back. Firstly (in no particular order) is that documentation is generally nonexistent, inadequate, outdated, or even actively misleading. When this isn't the case, it's too frequently written from the viewpoint of someone who already knows exactly what they want to do, they have just forgotten where the button is. I've been using computers for thirty years (running just about every common OS there's been over that time period), and programming for most of that - and I still come across too many cases where they're using a different term than I would have used, and thus it ends up being a steeplechase to try to figure out how to do what I'm after. I also am frustrated at how often I need to try going to the documentation in the first place - if it's a simple, frequently-performed task, it should be fairly intuitive, which would indicate that after as long as I've been using computers, I should be able to figure it out! The other downfall I've come across is a "complexity gap" - Linux is, in my experience, fine for a beginning user, and okay for a gearhead... but the people in between are kind of screwed. The basic stuff "just works", and if you are willing to hack scripts or compile code, you can do just about anything - but all too often, if you need to do something even just a little past the basic stuff, you *have* to start hacking scripts.

A LISP programmer knows the value of everything, but the cost of nothing. -- Alan Perlis

Working...