* Natural language processing (udacity nanodegree).
* Spanish words (duolingo).
* Random fields (reading random articles about it :-).
* Anonymizing text (side project)
* Photography (blogs, videos, and practice https://500px.com/la3lma)
Our summer intern Richard Bachmann just wrote a blogpost about his project where he connected one of our kubernetes cluster in the google cloud platform to a security monitoring tool we have running in Splunk (we = Telenor Digital).
Many interesting answers in this thread. But to get to your question: How do you skill up? My answer would be: As best you can, all the time. Find pockets of time and learning tasks that fit within them. Explore opportunities: Moocs, toy projects, more serious projects, read books, listen to podcasts during your commute, when you work out (which you should even though you don't have time for it), switch jobs from time to time, talk to people. Just never stop. One thing you should do however, from time to time, is to give up: It's not as if every learning task is feasible. Kids/work/family do put sometime severe constraints on what you can do. Some things just don't work out, and you won't necessarily know what they are before trying. So try lots of things, but give up from time to time when you have to. Learn about what your constraints are, and design next your attempt to fit them better, but don't stop. (.... but every now and then, you just have to find/steal/cheat to get some time to just hack, there is no substitute :-) )
> You have literally 6 features; you do not need to do dimensionality reduction here.
We do have six features, but they are not rotation invariant. I was hoping we could find the "axis of maximal motion" (or something along those lines) within each sample period, project the movement along that axis, and then do FFT to find what kind of bouncing around the test subject were doing. That didn't work out too well in practice, but it still sounds like the smart thing to do :-) What do you think?
For the right candidate anything is possible :-) However at this time everyone on the team is mostly located in Oslo so this is something we would have to consider as a special case. We're not primarily an C++ shop (we're not primarily anything really), but we do use some C++ in parts of the realtime processing code. We do occasionally use objective C when writing for iOS, but we haven't done that for many months now. Primarily we're using javascript, java (for serverside signalling and handset android apps), various scripting languages (python, shell, ...) and whatever is useful to solve the problem at hand.
It depends. I've interviewed many people applying for jobs (more than hundred, I don't know exactly how many, I've lost count). Applicants come in many shapes and forms neither can nor should be evaluated in the exact same way, so I look at many things when evaluting them: Do they have relevant education? Have they done interesting work? Have they done anything interesting outside of work? Can I have a good conversation with them? Can they solve the toy problem I give them? Do they freak out when I push them beyond their zone of comfort with respect of what they think they know they can do? One thing I've never done though: I've -never- frowned on anyone for leaving a job they didn't like.
hear hear. Won't happen in my lifetime, but if something like mathematica or ipython workbooks could become a common way to present an argument in a public debate then much would have been won.
btw: For presenting complex issues, journalism is dead. For uncovering hidden truth, not necessarily very complex ones, it's still very much alive.
I disagree, somewhat :-) There are people whose contribution is horrible but it's rarely confined to the quality of their code. It's more about being able to lead the company in directions that are ultimately wasteful in some way or other and not being able to change direction when the time is right. That leadership may be expressed in code, but the code is as much or more a symptom than the root cause.
With basic QA practices in place (peer review, coding standards, designs grokked by teams not individuals etc.) a single person usually can't muck up the codebase very badly. He or she can still poison a whole project or company.
Well, my understanding is that developer's experience changes the shape of the probability distribution of excellent/horrible contributions. But it is always a distribution. And that it is difficult to accurately distinguish between excellent/horrible contributions without hindsight.
I find that as I get more experienced, I'm more aware of how much of this huge discipline I don't know, and how many mistakes I've made in the past, and I'm much less likely to call myself a "good coder".
When I was younger and slapping shit together any old how, I thought I knew it all.
