tom_b

FTA: "why wasn’t the EHR already doing the legwork, displaying these potentially pertinent correlations and data points, painting a more descriptive clinical picture, instead of leaving me to wade through mounds of information?"

Because the focus of the EHR system is about billing and tracking medical record treatment for hospital administrators (auditing) rather than enhancing clinical treatment and understanding for MDs?

Probably a large opportunity here to do cool and better GUI and visualization, but good luck getting past the EHR vendor guard dogs to even read-only access the back-end data.

On one occasion at a meeting of a second-line managers entire org (4 or 5 teams), an employee questioning the utility of making patent submissions a numbers game (e.g, everybody better submit some) was told - with limited paraphrasing - "Hey, 1,000 people on the street want your job and will do the work plus publish technical reports plus submit patents for less money. You should keep that in mind."

I suspect, but didn't really know enough people in other software group divisions to verify, that this particular managerial mindset may have been more tied to our specific division than IBM "in the large."

I think at this point, most HN'ers would accept that a work sample test (of some limited scope and effort) is a better test than any interview question or whiteboard coding process. From that perspective, no question is really a good one. Unfortunately, at my workplace, there are strict rules in place specifically prohibiting this type of applicant process.

To be frank, knowing the difference in how to write an inner and outer join when given a three table schema and a desired output is a frightening filter of candidates. Having an instinct that some type of index could help a query probably makes you a db wizard.

My co-workers, though, are a little more stuck in traditional thinking on this topic. Also, a number of them are programmers "by accident" and so have maybe picked up one or two imperative programming languages. Simply saying 'Haskell' or 'Lisp' or maybe even 'node.js' would make it impossible for them to make any kind of judgement on a candidate. You probably wouldn't even get an interview, but we are also fronted by a HR machine with a frightening array of check-boxes to navigate through.

What are your thoughts about candidates who code correct solutions in a language not in use at your workplace?

I have a nagging feeling that some positions in my group have gone unfilled due to tech stack mismatches in candidates who were probably perfectly capable (or better) coders, but were most recently working in other tech stacks. Considering these types of candidates seems to be challenging in my workplace.

I've been developing an interest in statistical modeling and moving those models to production code (and of course, quantitative finance is an "obvious" place where this happens). But I find, even in the statistical genomics world, that the default process still seems to be:

  (1) specialized tools for data cleaning and initial crunching (maybe hadoop, maybe HPC clusters
  (2) consumption of data from (1) in R or Stata/SAS for model generation
  (3) only vague, research-y things where the model from (2) goes to production.

Specifically regarding quantitative finance, it would seem that trumpeting your implementation programming language would mainly be met with blank stares, Jane Street excepted . . .

The big win though is that he speaks the language and has direct hired his employees. This could be a catch for you if you are considering working with an outsourcing company. My friend is successful with his hires because he has the intangibles in place - speaking the language, occasional trips back to visit with them, works hard to direct hire (and keep) smart engineers, and he is personally vested in making sure he shares the "spoils" of the business with his employees. He also hacks on the platform, although not as much as in the beginning.

It sounds like you are considering a similar option, so you might be successful. You'll be putting in a lot of time though - frequent conference calls, code reviews, dealing with the occasional bad-fit, etc. In many ways, I think it would be harder than finding someone local to you.

For fans of hard copy, I recently found that if your local (university?) library is a SpringerLink customer, you can purchase a print-on-demand copy of either book for $26.99, which includes shipping. Interior pages are in black and white (including the graphs), but that is a really cheap price for these two.

Andrew Ng's course notes from his physical class at Stanford (CS 229 - Machine Learning) are extensive and available as well at:

http://cs229.stanford.edu/materials.html

You are correct that honeybees are a non-native species in North America. Sounds like the EconTalk you mention covered the topics in the book as well. I'll give it a listen. Thanks for posting about it.

I don't think I could write a simple echo clone in C anymore.

I miss C, but since entering the "real world" I haven't written a line of C for work purposes.

I'm not much of an object-oriented hacker, but when I was at larger IT firms, what several Java codebases shared was a common use of design patterns. It seems that this sharing of what may be considered a common vocabulary essentially makes it much easier for Java devs to jump into any project and follow the "accepted" usages in a way that perhaps other languages do not? So you are scaling up your dev team, it's infinitely easier to recruit acceptable Java candidates than say, Scala hackers? I do want to mention that my impression of Twitter is that there is definitely a polyglot JVM environment there (Scala, Clojure).

This feels like a bigger issue to me than I'd like it to be - in particular that Java programming opportunities vastly outnumber, say Ruby, Scala, Clojure, etc, hacking jobs.

If you are identified as a critical or especially-sought-after employee at a company in this situation, what types of retention structures and contracts actually wind up happening? Just curious.

Scary statement for me to read. I'm getting older and worry that the above thinking will eventually cut off cool and even just new opportunities for me. Also hard to audition for longer periods as suggested, but I'm definitely in favor of building a strong professional network and having a good portfolio of work.

Most time isn't spent programming anyway - programmer time is spent:

    a) fixing broken stuff that should not be broken
    b) trying to figure out what problem the customer actually wants solving
    c) writing experimental code to test some idea
    d) googling for some obscure fact that is needed to solve a) or b)
    e) writing and testing production code

For me, b) is a bottleneck. c) is far and away my favorite part. Nothing like green-fielding . . .

We ended up building a culture where managers too often compensated for the failings of employees by working around them, either working harder themselves, hiring someone else to fill in the gaps, or just letting the organization be less effective.

As an employee, observing these indicators should probably push you to change to a better situation.

My only recommendations are quite generic - for smaller meetups, make sure a group introduction is on the agenda and actually happens. Might be nice if there were easy ways to become more active in the group, but this is hard for the meetup/talk format.

I'm definitely not being critical though - I feel lucky enough to have a Clojure meetup happen in my general area. Mostly it falls back on me, as an interested-in-the-community hacker to find a way actually be social and integrate myself into that group.

Thinking about community effects, I'm not as convinced a community represents a gating factor for hackers. I attend the occasional Clojure meetup (and Clojure/Conj for that matter). The meetups in my area are well-attended and run, although they could be improved with a better introduction and ice-breaker for more introverted attendees (yes, I've just outed my personality type).

But from an opportunity mindset, the Clojure community seems to have done an admirable job getting the message out. Multiple good books, the Clojure/conj, and a well-attended meetup in my area all make me feel like I may not only stretch myself and learn new programming techniques, but that I have some hope of advocating for Clojure in my workplace or, good grief, applying for an actual day job where I would use Clojure.

It's unclear to me that Common Lisp can offer that.

There are other problem domains with similar requirements, but I'm quite curious to hear stories from other HN'ers who have tackled quantitative trading either for themselves and in the day job. Specifically, if you can share a bit on your technical work in such a role, that would be cool to hear about.

Commenting from the enterprise programmer perspective, I have seen talented, well-credentialed, strong portfolio-wielding, but lesser-networked hackers spend significant amounts of time (up to a year) on the sideline while seeking work in my region. Hackers should remember that this actually happens.

Build a bit of a cash cushion. Be prepared to invest in yourself (http://www.paulgraham.com/badeconomy.html). If you stay or return to the enterprise world, don't join a "cost center" group.

I will never forget the feeling of "you've got to be kidding me" when the code I had written was able to successfully classify a huge percentage of the validation image set. I really should head back in that direction and get with the machine learning.

Re: poker software. Before the feds crushed online poker, I had already given up on low-limit limit hold-em. It had clearly become a bot and augmented-player race. I would assume given game theory and Bill Chen's book that some enterprising hackers would encode pretty decent no-limit bots as well. If any hackers know anything about successful no-limit bots, I'd enjoy reading about it.

Another quick observation, not meant to discourage at all - we all lack in several areas. Always. I think for hackers, one of the only skills that matters is that you have established your ability to learn how to do details on the fly (like pick up a new language) while holding onto the fundamentals that help you stay productive and organized.

In other words - hang onto the "I have so much to learn" attitude, but be confident in your "getting things done" ability along the way.

Healthcare IT work (which I think we both know something about?) seems a little lower though, but jobs in RTP seem plentiful in that vertical.

The learning exercises might consist of simply coding up a few simple exercises in the areas you have listed. Pick a decently rated text and do a few problems.

The portfolio work should probably approximate working systems (e.g., mini-products). Since you are interested in web dev, throw together some working web apps that have full front-to-back-end stack.

Another option, and this one worked out well for me personally, is to take advantage of a cooperative education and internship opportunities. You'll gain a perspective on coding in the "real world" that you'll never get working on personal projects.

I am an experienced dog owner and currently have a super-intelligent and high-drive dog. But she's not a pet. Can't be allowed loose with the kids unsupervised. Has strong fear-bite drive. Is a "one-person" dog (although she has bonded with 3 or 4 adults).

If anybody is interested, I can probably provide more info or pointers, but in general, I think a good rule is to equate protective dog breeds with firearms. It's that big of a deal.

As a workaday hacker, my own practice has been more sporadic than I want. This talk reminded me that practice needs to be structured and purposeful. And regularly done.

The display resolution has become a drag though (same 1366x768 as the x220). I love the portability and durability of this machine, but I've notice I tend to hack when plugged into an external monitor more over the last year rather than just using the laptop alone.

I've started eye-balling the X230, mainly because you can cram 16GB of ram into it. I would also consider looking at some of the newish T430s/T431s. Better displays, still under 4 lbs.If you buy a Thinkpad new, get the cheapest configuration you can and upgrade the memory (I've used crucial.com) and drop in an ssd yourself - you'll save hundreds of dollars.

HIPPAA is mainly about having and following a reasonable process for protecting patient data, both at rest and in-flight on the network. I work with clinical research data, specifically providing clinical data integrated with research data. Mainly, I make sure PHI doesn't get shared with inappropriate readers. This can be a grey area when researchers are in clinic with a patient one day and the next are in the lab with their research hat on. Technically, all my work is covered by IRB approvals, which kick up HIPPAA requirements several notches.

Amazon put out a whitepaper on HIPPAA - skim it over, it's short and gives the high-level picture:

http://d36cz9buwru1tt.cloudfront.net/AWS_HIPAA_Whitepaper_Fi...

I think you can tell a compelling story if you make all your web app access available over SSL, follow the normal warnings from tptacek and crew on how to encrypt passwords and then harden access to the raw back-end servers. I'd recommend hiring a devops/sysadmin who has done this before.

If the security of the back-end is what your startup's selling point is, look into encryption options for your data store (e.g., encrypted by the RDBMS, or something similar).

Those are the types of concerns we try to make sure are checked off here as we work with patient clinical data and research data.

I guess the other thing to mention is that we use disk encryption tools as well - if a laptop walks off one day, we need to be able to say that (a) there is no PHI on it and (b) even if there was, you couldn't get it off (well, assuming that the NSA or equivalent isn't involved).

If you're funded/generating revenue already, maybe hiring someone like Matasano for a penetration test or process review would be prudent.

I'll ask around the research center higher-ups and update if I can track down a recommendation . . .

I worked hard to produce stuff at school (good grades and projects). I tried to establish respectful and mutually beneficial relationships with professors and other students. I gambled on hard (for me) classes when I realized they would sound impressive to others. I went on co-ops and internships. Then, at the end, I realized schools would pay stipends for you to go to grad school (a revelation to me, a first generation college student). Awesome, off I went.

I'm a little too rant-y with this, but what I'm really trying to get across is that a good GPA only happens by getting shit done. I agree that we could all use a little more resourcefulness these days but hope hackers remember that there so many ways to demonstrate that trait. I hope I'm never unimpressed by either the great github of profile of the self-taught hacker or the perfect GPA of the math/CS double major.