Cambridge is a wonderful place to live: extremely walkable, pretty architecture, good food, plenty to do, tolerant social atmosphere, very tech-friendly. Not sure if it's fair to call Cambridge/Boston a "terrible" place to live.
I would say that the weather and recreation opportunities aren't as good as in some other locations of the country, so you have a point there.
Good Rails devs are hard to find and in large demand. As a beginning Rails developer, though, you'll need to convince your new employer that you are a net gain. A junior dev can need so much hand-holding that they can steal away precious time from a senior dev.
Put some good Ruby code on github. If you can, you'll improve your chances of getting hired quite a bit. If you can't then you're not ready to be hired yet.
I'm actually making a part of my transition plan to attend an intensive course like those offered by General Assembly and CodeFellows.org
Those programs are designed to give me plenty of opportunity to put up live projects and public code. I have some stuff now, but it's so messy and noob-tastic that I'm not showing it to anybody for fear of being put in the stocks. It's that bad. :/
I'm throwing this out there as a tech lead who interviewed and made hiring decisions on juniors in the Austin, TX market.
First, working apps are big: put them on Heroku, link them up. I don't care how "straightforward" or "noob" they may seem, I want to know you're capable of shipping working products. If you can only get me 90% of the way to a solution, having to solve the last 10% for you on a regular basis makes you far less valuable to my team. Blog about the challenges or one interesting aspect of each of these projects: even 3 paragraphs can show me you know how to communicate technical things.
Second, GitHub all the things. Show that you know the "full stack": front-end markup, data modeling, a bit of jQuery can't hurt. HAML/SCSS are all the rage, not too difficult to pick up, and show you're "hip."
Third, go to Rails meetups: in Austin, we have a hacknight every Tuesday, and a monthly Rails meetup. If I've worked on a problem with you over a beer, your resume will naturally gravitate to the top when I have an opening.
All of those things are doable over weekends and evenings, and running with just these three tasks for 6 weeks would put you, in my experience, a hundred miles ahead of everybody else looking for a junior position.
I'm a tech lead who does interviews and makes hiring decisions for Rails developers, and I completely understand your sentiment, but I encourage you to push past that and publish anyhow.
More published code is better than less published code irrespective of quality, because it tells me that you're engaged and devoted to your craft, and it gives me a sense of what projects and technologies you're interested in and have been exposed to. Additionally, publishing code gives me a way to see your progression through the craft, and to get a sense of not only how developed you are as a programmer, but how you're growing.
A junior programmer who shows growth and improvement is a much better hire than a junior who is competent but shows no growth. When I hire people, I want to hire people who will grow into strong senior developers over their career, which means that I'm primarily looking for ability to learn and grow rather than a specific buzzword checklist. Hiring a junior comes with the expectation that I'm going to have to train and hand-hold them, but I want to hire a junior who will progress out of that stage, and will be able to start taking care of those things for new hires down the road.
Publishing code on Github doesn't mean that you're asking other people to use it; it just means you're publishing it. A Github profile on a resume is a +1 for me; a Github account with a lot of forks is another +1, an account with original code is yet another +1, and an account with original code that other people use is the big cherry on top. In all cases, though, I'd rather see an active account filled with "noobish" or "messy" code than an empty account.
I'm curious about GitHub and the code you review. Like many, I can hate my own code and sometimes feel that it will be used against me in a hiring process. So I guess what I'm asking is how much does it count against a potential hire that they have bad code and/or bad ideas on GitHub?
> More published code is better than less published code irrespective of quality
This is the path I try to walk. I'd rather put something out there than nothing at all.
Crudely speaking, no code < bad code < good code. However, what I tend to be interested in is curiosity and improvement in the case of a junior programmer. One technique I've seen that's worked well with me is for the applicant to list their 3 favorite repos on their resume, which guides me towards looking at them, rather than just poking around randomly at the "bad stuff".
As an interviewer, I don't care that you've written bad code in the past (any developer who says he hasn't is lying). I do care that you have written code up to the standard of the job I'm hiring for (which is going to be quite lenient for a junior position), but I'm mostly going to be looking for cues demonstrating improvement and curiosity. The more technologies, languages, and concepts you touch, the better. To me, your Github profile is a showcase of your interests first and foremost.
Well, not quite (when the messages are signed and the key is not stored on rails.org). However, as was pointed out, said attacker could indeed collect the ip-addresses of the polling servers - hence the idea to use twitter for the broadcast (a few comments down).
Of course Twitter is not exactly the most reliable platform but the likelihood of a twitter-downtime to coincide with a critical vulnerability seems relatively low.
That's why my keyboard layouts try to optimize for rolls more than any other layout I've seen. The most recent version has a number of very nice rolls, TH, IN, ST, and some other less-frequent digraphs.
If by failed you mean widespread adoption. But I have been using Dvorak since 1999 on a variety of platforms without a problem. It's a personal success for me.
"the trouble it is for them to manage different keyboard layouts in their head. I wonder if that's the same for dvorak layout users."
It's only on extremely rare cases that I've been forced to use QWERTY (such as at a public library) and when doing so, it hasn't been hard. So I don't have to manage different layouts in my head. I only use Dvorak, and my hardware and software supports it.
That said, I don't do any heavy typing on an iPad...
I think you misunderstand techiferous. This is what he said:
> “Dvorak […] failed.” If by failed you mean widespread adoption. But […] it’s a personal success for me.
I think by that, he meant, “yes, I agree that Dvorak failed, if ‘failed’ means not having widespread adoption. But I don’t agree with that definition of failure. Dvorak is actually not a failure, because I have used it successfully personally.”
techiferous means it failed to get widespread adoption but succeeded for him personally. In fact my story is remarkably similar. I adopted Dvorak around 1999 and have had no problems using it since. If I use a computer long-term I change the keyboard layout (but not the hardware). If I use a computer short-term I hunt and peck. For me personally it's been very successful.
Ah, that makes more sense. Thank you. Personally I don't see any keyboard layout displacing QWERTY. It's so entrenched in hardware, software, and people's minds. I think, if anything, it's more likely that voice recognition and things like Swype will displace traditional QWERTY typing. I can barely get family and friends to keep their phone or computer up to date despite it only taking a click here or there. A new keyboard layout? I may as well ask them to learn high level calculus. Even if we start by trying to teach an alternative layout to young children I just don't see it catching on.
Okay. If that's just food for thought, fine, but if that's an argument for widespread adoption it falls pretty short. In 2011 35% of the world's population were internet users according to a quick wikipedia reference source . That's 2.45 billion people. Taking the 500,000 Dvorak users into account yields 1 Dvorak user out of every 4900 internet users. I realize these are all kind of soft numbers we're throwing around, but I feel my point stands.
Community effects can never bring a poor technology to the top. They can keep a great technology from overtaking a good technology, though. But TextMate's success was not only from the community support, but also from its capabilities. Snippets were one of its cool features, for example, that helped it gain success.
Thanks for pointing this out, and I don't disagree. It's debatable whether TextMate was revolutionary or a huge leap ahead of the competition at the time. But batista claimed that "Textmate was always a sub-par editor" and implied that its success was due to hype, not its capabilities, which I find hard to accept as true.
I'm not claiming that TextMate was the best choice, just that it's unfair to call it a bad choice or sub-par. It was a very solid, decent text editor.
> people who don't have time to learn an esoteric system
if they had time to learn a programming language why they don't have time to learn how to speak with Vim? also I don't think that vim commands are more "esoteric" than (eg) objective-c
and actually, if you are short of time then you should learn to code faster with a faster text editor like Vim (or Emacs of you prefer..)
"I don't think upvoting-on-agreement problem can be fixed technically."
I think there is a technical fix: two orthogonal upvotes. One upvote/downvote pair for agreement, another for whether the post/comment added value. It's a pretty simple fix and I think it would work, but it could have other unwanted side-effects.
This could still perhaps be solved technically, although it would take a lot of effort and is probably not worth it.
You can detect cheaters. People who give up/downvotes on the "value add" dimension that are not well correlated with the community's opinion of value add would be detected as cheaters, or at least detected as users who do not share the same values as the community.
Much harder to do, but possible, is to detect cheating in agreement by analyzing trends. Users who agreed with story A, B, and C may have a 90% chance of agreeing with story D. A user who bucks these trends enough can be detected as cheating or randomly voting.
> With regard to the "giving", I wonder what theories there are about why many people feel good when giving things up to benefit others.
Imagine two cultural scenarios: one where everyone is looking out for themselves and helping no one, and another where people are genuinely concerned with each other and eager to help when needed. Which culture would you want to live in?
I think we tend to by default project our motivations onto others (especially in the absence of data). So if we are primarily selfish in our motivations, we think the people around us are selfish. So my guess is that being generous makes us feel like the world is a generous place.
Also, our parents probably taught us that sharing with others is good. So we get a little psychological "stroke" of affirmation about our inner goodness by being generous.
Regarding your post and the parent post: humans are primates, and in amost all primate species a social hierarchy exists, suggesting this is more than social accident when it comes to humans. So I see truth in both statements about giving -- helping others is always an act of power, the deepness (or flatness) of the hierarchy, and the perceived motivation and rewards (implied or conferred social status) may differ, but fundamentally helping others is an act of hierarchal positioning, and in most cases one that positively affects your position (or relative position anyway), so of course it makes one feel good - the reward centers of our brains are set up to be happy with better position.
That being said, I would still prefer the society where everyone helped each other out as, and it was a way to maintain status quo in the hierarchy rather than some act of "charity" (with the implications of 'I am your better by helping you out').
> fundamentally helping others is an act of hierarchal positioning
So you started with the idea that everything's about power, and then came to the insight that charity is also about power? If this were actually true, we'd have too many people willing to help. As you said, they just want to maximize their position in the hierarchy, right? In the volunteer organizations I've been in, I've never seen too many volunteers. (I'm in the 25-34 age group in a power-hungry East Coast city where people take themselves extremely seriously.)
Charity feels good because in our sacrifice we enter into another's needs on their behalf. This forces us to get over ourselves temporarily. I don't think it to be socialization; there's something more at work here.