I really like the skills section
http://nukaco.la/skills.html
I wish this was standard practice for resumes, even though it's subjective assessment it's really easy to compare relative strengths and weaknesses, for example it's very easy to see "dabbled in haskell, very proficient in garage band" just by glancing
I like it, but in 3 months she got 2/5 in rails, 2/5 in javascript and 2/5 in git? I doubt thats even possible...
I've been working with each of those for ~6 years and I'd still only put myself at a 4 and if I was being generous. It's funny the longer you work with something the more you realize how little you understand it. I probably would have put myself at a 2/5 in those categories 5 years ago, but looking back, I'd rate myself at 1/5 instead.
I think you should look at 1-5 or 1-10 scales logarithmically. It doesn't take a whole lot of work to become basically competent in a git or Rails (2/5), but to become an expert (4/5) takes exponentially more work.
Well, I didn't know there was a standard... for me it just felt "I know more Javascript than Haskell etc" so I put one more black square. So maybe I should change it to 2 out of 7 or whatever. :/
Aliz, I guess I was responding to the OP comment about resume's more than anything and didn't mean to offend. I really like your use of a scale, and your project is very impressive!
Wasn't trying to be pedantic, just giving feedback. In fact I totally respect the relativity of the scale, I would just say if it was for a job interview you'd want to maybe do as you said and adjust on a larger scale.
My point was 2 months in JS != 40% knowledge of JS. If that came across as pedantic, I apologize.
It might be a weighted 40%. As in, she knows 40% of what she needs to know or will encounter in real-world JS... or she's 40% as productive as she'd be with maximal fluency. There's probably a Zipf's Law over programming idioms where you can pick up the first half in a few months, the next quarter takes a year or so, and the last quarter takes more than a decade to encounter, comprehend, and be able to use masterfully.
Using a frequency-weighted metric, I would say that I'm 70-95% fluent (unknown unknowns make it hard to get confidence in a number) in my best languages, but I'm not an expert in any of them (and I'd only rate myself 3-3.5 on a 5-point scale, because percentage fluency on first-order concepts isn't the only important thing). I don't think it's hard to get to that point. Getting those last few percentage points is much harder.
I had an interview that asked me to rate various skills on a 1-5 scale. I think I gave myself a 1 in t-SQL and a 2 in C# even though I had been programming professionally in C# since the .NET beta SDK. I was worried they would pull out some crazy trivia questions and and try to trip me up if I rated myself too high. After I rated myself so low they almost didn't want to continue the interview.
I think most places are not like google where if you say 4 it means you invented the language.
I do a lot of interviewing and I almost always ask people to rate themselves on a scale of 1-10 in their primary language with a note that I recognize I don't expect our scales to match.
After they answer I ask what they learned last to raise their knowledge along their scale, what they're learning now to try to grow further (if anything, sometimes you're just executing not learning,) and if the candidate is applying for Senior Software Engineer or higher what "gotchas" they typically look for in a junior coworker/employee that would be rated lower on their scale (during a code review, for example.)
I usually get really thoughtful answers and gather a lot of insight about the candidates mastery of the language, mentoring and overall thought process.
You have to be reasonable about the scale. A 4/5 in English by your standards would also imply a deep understanding of root languages, old English, literature etc...
Becoming "fluent" in a programming language is vastly different from becoming "fluent" in a natural language. I hate when people make that comparison. How often does one ask for the etymology of the "if" statement and to what extent is such an understanding required for programming language mastery?
Actually, I think knowing the history and theory behind a language (as appropriate) is very helpful.
Particularly, if you're using a language like Haskell or Ocaml, it helps to have at least a vague idea of what a functor actually is and where the idea comes from. (I actually only realized that functors were actually similar ideas in both languages a couple days back.)
On the other hand, if you're using a language like JavaScript, understanding the history (especially the languages that influenced it) makes understanding some of the "quirks" much simpler. When you see the influence of Scheme, the scoping suddenly makes much more sense, for example.
So, over all, I think understanding the background of a language really helps for complete mastery.
> Particularly, if you're using a language like Haskell or Ocaml, it helps to have at least a vague idea of what a functor actually is and where the idea comes from. (I actually only realized that functors were actually similar ideas in both languages a couple days back.)
I could not agree more! Understanding the significance of particular keywords is quite important when failing to do so will affect your ability to successfully use the language. I distinguish that from my argument, which I premised on such knowledge not affecting one's ability to successfully use the language.
If she would put 3/5 (like you imply) I would think that she as B1 level or something like that. She is not native. If she was a native the scale would be different.
As if rating one's skills in a particular subject with a 1-5 rating under no context bears much meaning... it's so arbitrary as to be insignificant (but it could be a cool concept if not abused). It also depends on one's motivation for representing their skill level; for example, jobseekers probably overestimate their skill levels.
It would be great to have a standardized rating system based on a few different tiers wrt a language/framework/etc.:
1 - Wrote some really basic code in the language
...
5 - Wrote some really, really advanced code in the language
On my resume, I have a "skills" section that basically lists technologies I've worked with that I'm interested in working with now (and some I haven't work with) with a "code-word" based description of how I'd rate myself. The "code-word" selection will beat most HR folks, but I include a "decoder-ring" style description in my cover letter on what I mean by those code words. Things like, "familiar: know at least basic syntax and can easily use all syntax with reference, will likely need to use a reference for common libraries" and "expert: Need documentation only for infrequently used or obscure library calls, comfortable writing a tokenizer and lexer for the language given the specification". I actually got the idea when I applied for a job way out of my league and actually got a response explaining it was out of my league, so I asked for some feedback on my resume, figuring don't let a good thing go to waste and the response was "years of experience in a language doesn't quantify your knowledge of the language." I was quite young at the time and the approach I ended up with hasn't steered me wrong yet.
I'd put 5 at "wrote the language or contributed to the language". So 1-5 on Python where 1 is completed first tutorial book, written a non-trivial program. 5 == Guido Rostrum / contributed to a release. 3-4 would be if you have written a compiler.
Since the scale is only 1-5, saying that only a few people in the world qualify as a 5 or even 4 wastes 20% or even 40% of the expressiveness of the scale, which makes it pretty useless. It's better to round in the other direction, and think of the scale as logarithmic. If most people in the world won't have any ratings in the 4-5 range, that makes it pretty useless for comparing your own proficiency in the languages you do know, which is the entire point of the exercise, not comparing yourself to the people who designed the language. The interesting thing she's trying to express is how much better she knows JavaScript than Ruby, not how good she is compared to Brendan Eich or Matz.
I mean how advanced can you be in a scripting language ? There is no memory management, no low level systems knowledge required. Can you give me an example of writing really really advanced code in Ruby or Python ?
Managing memory and using low-level system functions is only advanced when the problem at hand requires it. Otherwise its yak-shaving. It would be like digging a pool with a spoon because you're too bad-ass for shovels.
You've been downvoted a decent amount, and I can see why, but I believe it is unfair because it's only due to your perspective.
At one job I ended up having a lot of work writing language bindings from C to what is commonly considered a "scripting language" (TCL), so it's easy to have to deal with memory management and low level systems knowledge in relation to a scripting language (knowing the semantics of memory management within a language drastically changes how you have to write the bindings). However, the idea is to rate your skill with that particular language. No matter what the most advanced state is of a language, a 5/5 (or whatever the scale is) means that you can accomplish the most advanced task possible in the language. That doesn't mean that someone who is, say, 5/5 in Perl, will have the same skillset and capabilities as someone who is a 5/5 in AT&T syntax assembler. However, there are a list of base assumptions of skills they do have that may align with what we need as a developer when looking at resumes.
"5/5 (or whatever the scale is) means that you can accomplish the most advanced task possible in the language"
I appreciate your sympathy. I have no problem with people who are born into scripting languages. Personally I started with C, C++ and worked on few scripting languages. My question came from more of curiosity. There is more learning curve in low-level languages because the very structure of your code can affect the memory foot-print of your programs and that requires careful crafting of data-structures and algorithms. At a scripting language level you are in a virtual "world". It does allows you to SOLVE pretty advanced problems but it does not necessarily translate into your expertise in the scripting language itself. For example, I might use Ruby to create true AI system but in the end its the algorithm that mattered not my knowledge of the language.
I don't know how much effort you put into learning high-level languages, but people coming from C tend to keep writing "C" in scripting languages as well.
While that can work, they miss out on all the cool and more advanced stuff these languages has to offer.
People downvoting: this guy is admitting to his ignorance and actively and constructively asking to be challenged on it. I don't think that's the kind of comment we want to downvote here, even if the tone makes you bristle.
Also, you may have to reevaluate your definition of a scripting language. I will try to guess as to what it could mean to you currently:
A script language is interpreted, a non-script language is compiled
First we have to define interpreted as it could mean many things itself. The most restrained vision of interpreted is a language that would take one line (or enough to form an understandable command), eval() it (which means parsing the line, executing it and changing some internal state) and then proceed to the next one. There's a second case, there are languages that parse the whole content into an tree (precisely an AST) and proceed at evaluating it. A compiled language will have to first parse the code into an AST, then proceed in transforming each node of the tree into a set of smaller instructions, then encoded as bytes. The resulting bytes are called bytecodes and they can be either native or executed on a virtual machine (which translates them to native bytecode). Fewer and fewer languages falls in the first case; PHP3-, older JavaScript, Perl 5 and Ruby 1.8 (MRI) in the second one; PHP4+, Perl 6, Python, Ruby 1.9 (YARV), modern JavaScript, Java, C# in the last one with a VM; C, C++, D, Go and Objective-C in the last one as native code.
A script language has limited tools, a non-script language has a sizable standard library
Take for example (ba)sh: it is really a glue language that controls flow and calls external programs. Those are called shells. As convenience and for performance, shells often include in their own code implementations of previously or current external programs (e.g test, aliased to [) or allow to control or use features specific to the shell. Those are called builtins.
Now you can compare the size of the C/C++ sdtlib and e.g Python, Ruby or Java. The latter ones are an order of magnitude bigger than standard C and C++.
A script language has no external library facilities, a non-script language has third party library facilities
The only thing resembling library features of bash are sourcing an external file and executing external program (which is native enough to extend the language itself since command-calling is first-class in shell languages). On the contrary python has extremely advanced library facilities called modules and packages, which create namespaces that you can selectively import. Ruby is simpler and arguably less advanced as it relies on a 'require' and a 'load' function that will trigger loading and interpretation of a file, while namespacing lies in the hand of the developer who manually nests classes and modules. This is similar to the 'source' feature of bash, but also of the #include preprocessor directive of C, which is not even really part of the compiler and literally stitches the content of a file into another. Usually this #import is done to include so-called header files that describe prototypes of function lying in a library. What's interesting there is that the library feature is actually not even part of the language, but of the infrastructure surrounding the compiler, and precisely the linker. Indeed compiling to native code results in object files which are totally independent of the actual language and totally dependent of ABI calling conventions (which is really unrelated to the language). This way you can link objects having been built from fortran or C, or C++, or whatever. So it turns out C #include is actually closer to bash 'source' in that regard, with the onus of library management being not on the compiler but on the linker.
A script language has no types, a non-script language has types
Bash actually has types, precisely strings and arrays and it's up to each program to parse the strings into somethign meaningful. Now what you may be distinguishing there is weak typing vs strong typing. Let's take PHP, which when given "3"+2 spits 5 (or "5" I can't recall). Try that in C and you will get an error/warning/core dump (ironically '3'+2 in C would give both a warning and '5' because of ASCII and char really being bytes). Yet try that in python and ruby and you will get an error (an exception precisely). PHP is weak-typed and Python, C and Ruby are strong-typed.
Now maybe that's because we're not declaring types and not having function/method signatures that makes it a scripting language. Really what's at play here is static vs dynamic typing. Python and Ruby are dynamically typed, while C is statically typed. But Objective-C is dynamically typed too.
A script language is used to write scripts
Maybe you encountered #!/bin/sh in scripts, and also #!/usr/bin/python and concluded 'Ha! They're scripting languages!'. Amusingly enough, it's quite easy to build a thin wrapper to gcc that will make it possible to start a file with #!/usr/bin/c and subsequently write code in C. Does that make C a scripting language? Maybe, but that makes it equally easy to make any language a scripting language.
A script language is not written in itself, a non-script language is written in itself.
This is called self-hosting. You could argue that C is written in C, while Bash, Python and Ruby are written in C. Well too bad, as D is written in C, C# is written in C and C++, Java is written in C, and even g++, the C++ compiler is written in C. (for each one of course, part of their standard library is written in their own language). At the same time, Python has PyPy which is able to produce native code straight from Python code, and various other languages are self-hosted. Now you could argue that we're using C because of performance, but that's not even true, since PyPy regularly outperforms CPython. In fact we're only often using C because there has been a tremendous amount of work thrown into C compilers (notably regarding conversion of code to each native platform) so it's merely by convenience that we reuse them.
A script language has no memory management, a non-script language is low-level
So, C and C++ have memory management, while Python does not. So much for Java and C#, which would become scripting language by that criteria. Also, as for low-level Python can use things like mmap and has ctypes which allows you to tap into system devices (via e.g /dev) and native functions (which, as mentioned above may or may not have been written in C, since at that point they're just native code respecting a convention allowing them to be called. If anything such code could have been generated by PyPy) like malloc and free, so you can go low-level in Python if you wish.
So I think we have made quite a round-up of things, and hopefully enouch to demonstrate that well, while Python and Ruby are effectively able to be used (and quite efficiently so) to write scripts, they are clearly just not only "scripting languages", but full-blown, extremely advanced and potent programming languages.
Great roundup. Its nice to see all this points. One big difference between scripting and non-scripting languages is that, in scripting languages you can modify the structure of the program at runtime, while in compiled languages you are stuck once you compile it. C++ does have metaprogramming through the use of templates and those programs look immensely complicated, but it can't introduce new data types and logic at runtime. I kinda dislike C++ from beyond templates as the code looks super ugly.
The ability to modify the program at runtime (and elegantly) is a huge advantage over compiled ones and allows you to express new category of solutions.
Programs that change itself is in my opinion pretty advanced.
So it seems, Python and Ruby allows the programmer to free the mind from the low-level housekeeping and focus 100% on logical thinking and give incredible expressiveness. I would buy that.
I wonder how often an above average python/ruby programmer use its metaprogramming / reflection capabitlies?
I once had a professor teaching a course on elegance in software design proclaim "Python is not a real language". The course is taught in Java. I cringed.
How about PyPy? It's a Python JIT compiler written in Python.
There are thousands of other examples. Managing memory and low level system is not the difficult part, it's just tedious - algorithms and mapping a problem correctly is the difficult part.
the way i think of my language skills in my own head is mostly a three-level system: read, write, and debug.
at the first level, you know enough to be able to look at existing code and have some idea what's going on. (this is me with C++.)
at the second level, you know enough to write new code with real functionality and have some chance of its working. (this is me with C.)
at the third level, you have a fairly thorough understanding of most parts of the language and know idioms, common pitfalls, etc., and can fix other people's code. (this is me with q, and it was me with java seven years ago when i was working in java.)
if you want to extend this, an extra level up could be "hack", where you contribute to the language itself--modify gcc or the python interpreter or whatever. (i aspire to get to this level in q, and i think i'm close.)
not sure how to wedge a fifth level into the system....
I typically just list things I've worked with, no matter the experience level. I like to do so because then the interviewer has to ask about them in an interview, where I'd then get a chance to (subtly) showcase my knowledge and enthusiasm.
From my own anecdote: I had an interviewer ask me about something I had listed in my resume (but not related to the job position). It made for good conversation and allowed them insight that they otherwise wouldn't have seen with a straight technical question.
Edit: Hopefully I didn't go off topic with my comment, but I also think the graphic indicator was a clever and very straightforward way of expressing experience level. It just doesn't seem very space efficient if on a paper resume.
I disagree, because of the subjectivity. For some things, it's fine, but for others, I don't think it's an accurate reflection.
For example, what actually quantifies 1/5 of Ruby? And does a 5/5 rating mean you know absolutely everything about it? Is 1/5 of Ruby the same as 1/5 of Python, or soldering, or speaking Icelandic?
There's also no improvement from 5/5, but even a master of their craft will know there is always room for improvement and greater mastery.
That demo has a lot of javascript going on, and she rates that 2/5. I don't think that demo is trivial to implement, and on relative terms I can assume that she's more than just dabbled in Haskell and Python.
We know she's German, so she puts 5/5 in German language, as it's her native tongue. If that was the base, does that mean she's as fluent with Garageband and Logic as she is speaking?
I don't think skills are so easily quantifiable, and I'd much prefer to see a qualitative analysis of those skills. Otherwise, I'm just looking at a meaningless pattern of shaded boxes on a page.
From an interviewer's perspective though these kinds of ratings are still useful. They just need to be calibrated.
If I were hiring this person it would take less then 10 questions about one language to figure out where her competency is according to my scale and now (assuming she didn't fudge too much) about her competencies with others (some of which I may not know).
Another approach could be to normalize everything against your best skill. So rather than saying "I'm this good at X", you're saying "I'm about half as good at X as I am at Y."
I think the tricky bit would be making your intentions obvious.
I actually took a similar approach on my résumé: I broke my skills up into categories relative to each other rather than vying for some absolute quantification.
I found it hard to figure how my resume could summarize the breadth of my knowledge. I ended up putting a table up with "Good knowledge of", "Some knowledge" and "Worked with" in my resume, listing each skill under one of the three headings. Gives a pretty general idea. Then again, during interviews for the job I'll be starting soon no one asked me a single technical question.
My reasoning of that is that it's a two year "traineeship" (widely used term in the Netherlands, seems less so abroad), which is more of a dive into the company, with extra coaching and mentoring at two different positions within the company. Most interview questions were of the sort "how do you work in teams" and "where do you see yourself in 5 years" - much harder to answer than technical questions :)
It looks neat, but I'm not sure it would help her find work, if that was the purpose of it. People seem to be more likely to find and hire you when you're easily classifiable—say, “JavaScript front-end developer”, or “Mixing engineer”.
I'm sure many people are good (or could be good) at many unrelated activities. I had an idea of personal portfolio that would encompass all of my interests and work, too. But in the end I chose to market myself as “just” a programmer. Knowing about my proficiency in Logic or InDesign or playing piano won't help anyone looking for a programmer, and if by chance I rate my Python skill lower than InDesign or, say, OS X skill, I'm pretty sure it will turn away many paying clients.
I decided to go with discrete “brands” for various activities. Failing at that currently, though (hard to manage).
> It looks neat, but I'm not sure it would help her find work, if that was the purpose of it.
If this is true, we live in a truly depressing world. I don't understand the point of an interview any more. I sit down, lie to you for an hour, you Google the shit out of me, stalk me on Facebook. But if I tell you who I am honestly? Trash bin.
Why would you lie about yourself on an interview? An interested employer is unlikely to drop you because you are also proficient in, say, Final Cut.
The question is, how do you get to the interview?
It's simple: if a potential employer or client needs a Java programmer, they are likely to look for a “Java programmer”. Therefore, if you have a website that says “John Doe, Java programmer”, you seem more likely to get that job than if you only have a website about some John Doe that has Java listed somewhere among his multitude of skills.
Your website is probably made for other people. In that case, optimize it for other people. It seems easier for them when they can “classify” you. People who could appreciate your complex personality are your friends (and maybe family), but are they probably are outside the target audience of your website.
This is a good example of how people should learn coding. Not doing examples but doing something that is very goal directed (for her doing a website). Exercises should help you understand how to do a final goal. This is pretty impressive for only 3 months of study also.
I've been bugging my friend that he should learn to code a website for the past few years. And for the past few years, he's been stating that "its not for me" or that "I'm not the techie type". I hear this all the time from people who don't know anything about coding.
A few months ago I showed him a demo of my website (artJutsu.com WIP) and showed him the basics behind the code. I also showed him how to create a simple site. The dev site (on my laptop) has many different concepts that I'm still hammering out. To him it looks complex, so I told him that it doesn't have to be.
I gave him the following advice for why one does create a program. "Just think of a "simple" problem that you'd like to fix. It doesn't have to be super robust, or super smart, or super technical. Just try to solve this problem through an elegant interface."
For me, artJutsu (once I get the main part completed) will solve a variety of small problems. Yes, there are things in it that is very complicated, but that comes from research. We're in an amazing time as developers where we can access a rich array of resources just with a simple Google search. The great thing is, the simplest solution usually solves the problem just as well.
I always was the type of person that hated reading those coding books and doing lesson after lesson with very little getting done. For the most part, you don't really know WHY you need to know techniques and theory. Its just way too confusing. I find getting down and dirty building something teaches you a lot more. Theory is great, but what good is it if you don't know that you need to know it? I believe that getting your feet wet will enhance the traditional learning experience.
Anyway, after a month of coding, my friend has created a pretty good "list" site for his wife. He's at the point where its getting tough to maintain his code, but he loves it. The joy of creating a useful tool to solve a problem is what we thrive on.
Almost invariably when we see posts like these on Hacker News, the person actually had prior programming experience, but just happened to start taking it serious for the last [small number] [unit of time].
Actually she might learned to code in 3 months, but shes coding much longer I guess. e.g She wrote in her XING profile that she started studying informatics in 10/2010. Despite that, consider marrying her :)
Yup, I started studying bioinformatics in 2010. I chose bioinformatics, because I was interested in biochemistry and biology and wanted to learn how to code. To my disappointment uni did not teach me much practical things and programming courses (Haskell) were really boring. I would find myself sitting over a really dull homework in the middle of the night thinking "It's so stupid and boring. I really don't want to do this. I want to do more fun stuff... like coding a game or so.". Well trying to code a game in Haskell turned out to not be the best idea. Especially if you don't know how to code yet... and then I just stopped going to classes.
3-4 months ago I wanted to make a band, but had a hard time finding musicians. So I decided to learn Rails and HTML etc to build a web application which could help me (and others) find some musicians. In the end I never really officially launched it but learned a lot and found that I enjoy coding. :)
Don't blame it on Haskell. Everyone has to learn the fundamentals. Haskell is suited for making games, it's just not the mainstream language for that. See http://www.haskell.org/haskellwiki/Frag . Yes, 3D games have lots of tricky state handling and OpenGL doesn't map well to Haskell. But doing a point-and-click adventure in Haskell is not harder than doing it in C++.
I really doubt your classes were stupid and boring. Maybe you were the one who was stupid and boring :P
I have to say I like Haskell and I don't think it's boring at all. I just wanted to learn more than they were teaching us in uni. :) Haha, I even played around with HOpenGL...
Wow she is awesome. This music hack day project is intensely beautiful http://nukaco.la/projects.html
It is a musical umbrella! That synths sound as it is hit by water!
I'm insanely jealous of your gf. I've been doing programming as a hobby for nearly 10 years and haven't knocked out anything as cool at that.
Nice skills section too. I might make that as an extra attachment page to my CV.
Ask her, Python or Ruby and why for me.
3 months of programming and already had a glimpse of Haskell, I'm really impressed.
I'm struggling to find time to learn it a little, and during the last 10 years since I first heard about it I hadn't had enought time (the only haskell code I "do" is xmonad.hs :)
Daniel Tammet learned to speak Icelandic in a single week. Unfortunately, like your girlfriend, he didn't share much of a guideline for others working towards similar goals.
Aliz, this is awesome and your bf is awesome for supporting you in learning to code. Also - speaking ANY Icelandic is kind of a big deal! Hope I'll meet you sometime
Basically, for ruby and javascript we had (very informal) coaching sessions together roughly once a week (around 2 hours each). I would walk her through core syntax problems (how to use functions, objects, arrays) and give her some hints of what APIs to look for. And then she went and researched and tried a lot of stuff (sometimes more than 8 hours a day) and would ask me when she got totally stuck. I would then try to not give direct answers but hint at where to look for or how to develop some sort of divide-and-conquer strategies. And then I was kinda amazed at the results ;)
