Well just FYI then (Shoe Lace this is for you or anyone else with a bunch of node/angular experience too ) - right now we have an ATG/Weblogic-based separate mobile and full site - that both handle a bunch of different functions and are fairly gargantuan. We're converting the whole thing to a responsive site based on connecting node/angular/bootstrap/etc to an API back end. So it's exciting to me at least, because rarely at a large company do you get a chance to completely start over from scratch using the latest cutting-edge technology.

As far as the situation, I can honestly say I've worked in a bunch of places and I've never been at a place with this kind of chemistry. No one is really a snake in the grass, everyone gets along, and it's a pretty social group. It literally hurts when someone leaves, like losing a family member.

I'll PM you the rough pay expectation.

The wonderful thing about using a rare language is that you get to tell everyone that you use a rare language. The downside of using a rare language is that you *have* to tell everyone that you use a rare language.

I'm trying to wrap my brain around this. Suzzer lives in Los Angeles, which has 3 of the top 50 universities in the nation (Cal Tech, UCLA, USC) and there are zero good programmers available???

If nothing else, there is this one school in SF that focuses on Node / JS stuff: http://hackreactor.com/

I'm really lost at how people make it like it is so hard to find developers in Los Angeles. Using craigslist is of course a joke idea since no self-respecting programmer would search for a job there.

It's hard. It's a parlay.

1. First you have to find someone who is naturally a good programmer.
2. They have to have enough experience in the particular technologies your company uses. Training is a possibility, but that wastes time and money.
3. They have to be a good worker. Lots of talented / smart people need the right circumstances to be motivated, or just aren't motivated period
4. You have to want to work with them. Their personality needs to fit with your and the company's culture.

Lots of stuff has to go right.

We're still in a social media bubble. There is a ton of dumb and smart money being thrown at anything social and/or mobile right now. There are 1000s of startups who will never actually see the real world, but will pay real wages for a few years while they try. There just aren't enough good/experienced web developers to go around.

Even harder still is finding a seasoned, talented web developer with the communication skills, attention to detail, decision-making ability and big picture awareness to be a project lead. We interviewed one guy who had worked at Citrix for about 10 years. I was really excited because it seemed like he could drop into a lead role right away. But apparently he wanted way more money than our corporate pay structure could handle. And we don't pay bad. He'll probably find it somewhere. That's how in demand those kinds of people are.

It also made me realize I'm probably underpaid right now. But I know being the "node guy" and overseeing all of the front end angular framework will make me much more valuable down the road. So I'm not thinking about going anywhere for a while. Plus it's 15 minutes from my house and like I said, like a family. That's worth a lot. I'm old enough that I may consider being a "lifer" if the work stays interesting and I can get lots of time off for photography.

I may have the wrong impression here, but I gather that Cal Tech, UCLA, and USC aren't exactly easy programs to get through. I know they are widely respected and I've seen more than one job ad demand a masters from one of these schools as the bare minimum.

He's using techs that are, at most, 4 years old and don't have much mind-share. Seeking someone with experience is unrealistic. That's the risk:reward you decide to take on in this situation. If you want insurance, use Java or C#.

Training will have to be a part of it. Grant it, he can let some other company do the training, but that feeds the "no experience" dragon since no one else is really using Node. At some point, just gotta call the career services at some college and offer a job paying $15/hour to a relatively bright student or do what everyone else does: post ads for internships.

I"m just not buying into the notion that someone with wide experience can't learn.

We don't have to have years of node or angular experience. Just being a rock solid JavaScript or CSS developer is enough. And those are still really hard to find. Obviously solid node experience is a big plus in our situation.

I don't care where you go to school, or what advanced degree you have, it takes a few years of experience as a developer to really learn how to program well. IMO someone straight out of high school with talent is still going to be way more productive than a mediocre developer who happens to have some kind of PhD in computer science.

I have worked with PhD programmers didn't know their ass from a hole in the ground. They didn't realize that you actually have to make every little edge case work in the real world, messy browser output environment - and tended to lose interest at that phase of the project – which is 80% of the work.

The one guy I'm thinking of in particular came highly billed as some kind of genius. He had gone straight from getting his doctorate to a start up where they really didn't produce anything for two years. I think he may have been ruined for life, because he was totally useless. Before we realized what he was doing, he spent his first two days writing his own System.out.println, because he didn't realize Java had a built in print to STDOUT function.

Point of a phd isn't to get good at coding, it's to publish papers. Being a computer scientist and a programmer are two fairly different things, so expecting all CS people to be good at web programming is a mistake. It's almost as unreasonable as expecting all devs to be good at design. Front-end guys will tend to be, but will systems guys?

For the guy you described, if he wasn't good enough at CS to get a job writing papers and he didn't learn to program well after two years at a startup, he probably just sucked in general, i.e. was both a bad phd and a bad programmer.

Someone with a PhD should (in theory) have elite research skills and be good at learning stuff and becoming an expert at it.

Depending on the school at least decent people skills should also come bundled with the degree (teach classes, interact with other scientists and students etc.)

I think bashing folks with a PhD has gotten a bit out of hand in IT in general. Yes there are guys that will be horrible at programming but it almost feels like "ZOMG stay away from these dumb PhD folks yo" has become a trend (i.e. assume they suck rather than they don't)

And basically this.

Thanks for the consideration! There are some enticing things here, but I live in NYC with a wife and a kid, and it would take an exceptional situation for me to move somewhere else that's not Boston or Bay Area, where we have family/friends/etc.

I've also worked hard to carve out an amazing position for myself at my company and there are probably a lot of mismatches between most front-end dev positions and my general technical/career interest. I learned Javascript/HTML/CSS/jQuery/AngularJS over the past few months because the web side of our product needed a reset and no one else could lead the project, not because I have much interest in front-end/web development. Leading this effort means I'm now more or less in charge of all engineering as I was already the technical lead on the other, non-web side of our product. At this point, I'm the only developer with full trust of all of management, which explains how I got to lead the development of our web front end, despite having close to no professional experience in web technologies. I make every major technical decision I get my hands on, and better yet, have those decisions either emerge as engineers' consensus or come down from management. It's awesome to have no formal managerial responsibilities, but to have enough respect of management and other employees to be the go-to guy for all high-level technical decisions.

The only thing missing is high compensation - too much of my pay is locked up in equity (I may be the only engineer with equity compensation), so if it turns out that our company isn't worth anything, I will have been underpaid by a lot.

Hahaha, I'm almost you, at my company. Minus the old/lifer part

That's a funny story.

I know that there are a grip-load of dev-houses in Los Angeles with bad programmers, still using table layouts, writing bonkers code, etc. I know that there is probably more money to to be made in "social media," but I still can't purchase the idea that it is impossible to find a good js dev. I linked to that school in SF for one and I am trying to have enough faith in humanity to believe that people are interested in more than ad-clicking.

Have you looked into contacting one of the organizers of the Node meetup groups? I see a few in Los Angeles.

Nodejs / HTML5:
http://www.meetup.com/Burbank_Hackers_Club/

Nodejs:
http://www.meetup.com/nodela/

JS:
http://www.meetup.com/FoothillsJS/

Nodejs:
http://www.meetup.com/SoCal-Node-JS/

Angular:
http://www.meetup.com/socal-angular/

There's plenty more I am sure. If the Clojure meetup is any indication, I'd expect you to find some damn good talent at one of these places.

Eh, I'm not going to spend a lot of time recruiting for my company. But if someone walks across my path that knows what they're doing I may try to talk to them.

As far as PhD's, I'm not saying they're all terrible or anything. I'm just saying that we look for solid experience over someone with a major academic pedigree, because they still have to get the experience and there's no guarantee they're going to be a great program.

We had to teach one of our "senior" infosys front end devs what an HTML table is. True story.

suzzer99,

Thanks for the mention but my plate is pretty full at the moment. If you hit any road blocks or have any problems shoot me a PM or post the problem here. I'll do my best to help.

Thanks.

We had a guy out for the last two weeks from a company called Skookum Digital in Charlotte, NC, who knows on about node, angular, git, among other things. Hopefully he got us on the right track at least, and kept us from having to learn everything the hard way.

Did he set you guys up with a reasonable work flow?

Yeah, but I don't know if it's gonna slow us down too much having to do pull requests and have someone else merge every time we want to push something to master. We're pretty used to not breaking each other's ****, checking stuff straight into the repository in subversion. So I don't know that we need that extra layer of open source–like protection from breaking the build.

Even when we check in the master, it's still a long away from making it to production code. There are ever-increasingly stable testing and staging environments that it goes to first, managed by a dedicated buildmaster. We typically have 4-5 large projects running at once, and a whole bunch of little fixes going on. That requires a lot of merging different branches into each other, and a defined strategy for doing so.

However, I can see the major benefits of having to list out in bullet point form all of the functionality that you just added - so that someone else can test your code during the pull request. It's nice table to go look at that, and have more than just one liner checkin notes. Project managers can use that to track progress as well. Also since we have a lot of crappy offshore developers, this will help us to review their code.

So we'll see how it plays out.

The biggest thing he set us up with, which will be a major change, and I'm very nervous will go out the window once we get into crunch time – is test-driven development. Every place I've ever worked as always talked about automated unit testing, but then they never go through with it. We're using Zombie and Mocha to write quick tests of everything we do. It's going to be my job to make sure that everyone sticks to it long enough, until we're used to developing that way.

Code Reviews -

For quite awhile there were just two of us writing code at my job and we're both senior and just committed stuff whenever. We got an intern a year ago and realized we needed to start code reviewing his stuff. We found it so awesome that we kept doing it for everything even when it went back to just the two of us. Now there's half about 8 of us and its super useful.

TDD -

I don't think I could work for a company that *required* TDD. I find the code reviews are a good way to ensure sensible (ie. not 100%) automated testing.

Edit: Also your build/deploy system seems crazy onerous. We've been moving more towards the continuous deploy (not just build) side and I'm definitely loving it. We're up to a couple of releases a week and its way better from my past life where we did a release for a project every 3 months or so.

We always do code reviews. But pull requests seem like they would actually enforce a code review every time something is checked in. We would catch it sooner - rather than when we do the code review and the code has already been checked in for a week or two.

We are looking at continuous integration as much as possible. But there's a lot more moving parts involved than just code. We have multiple projects going on, with their own budgets, their own timelines for going live. We have to coordinate all that with a bunch back end services which are completely out of our control.

TDD may be a holy grail for us, precisely because of the reason I just mentioned. The site is so gigantic, with so many different groups working on it, that it's scary to change anything anywhere because you're afraid you're going to break something somewhere else. Also we are a CMS-driven site, so producers can add all kinds of crazy crap to the site that we aren't even aware of. Usually when we go live will do some kind of A/B testing for a while, which means old code hangs around forever, and people are scared to remove it.

There are a bunch of other factors that make it really hard to keep control of our code base. I'm hoping TDD will help us greatly on this issue. I'm definitely willing to give it a real shot and see what happens.

So... that interview for an internship I thought I bombed talking about OO and databases: I got it and I start tomorrow!

Absolutely excited by this. Couldn't have done it without the incredible guidance from you guys.

Thank you, all.

congrats dave! makes us proud

dave, you are awesome! hope you love it.

Congrats Dave!

Suzzer, we do all our code reviews with pull requests. I love it.

You guys sound very similar to how things were like when I started at my old job. It took a lot of time and for lack of a better word political capital from everyone on the dev side to make people realize it was a really poor way to do things.

It involved splitting a massive source control system into independent git projects, focusing on clear shared services, investment in tooling, etc.
I have no doubts that it was worth it but I understand the cost and how it was hard to swallow from upper management.

I also forgot to mention that you hit one of my many pet peeves with TDD when you were describing why it was necessary.

You described why you need tests. Not why you specifically need Test Driven Development.

I think the standard response to that (which I mostly agree with it) is that unless you're doing TDD the tests, in a practical sense, just won't get written, and if they do, there won't be as many of them and their quality won't be as high.

Of course there are other reasons too, such as TDD's forcing you to design everything with a view toward interface rather than implementation, and having to write thing in a testable way forces you to create composable pieces and use DI rather than hardcoding dependencies.

EDIT: I would add that the dark secret about TDD that most people don't discuss is that in many cases the available tools, and setting them properly, make doing it a real pain, so there is an up front cost in that sense.

Ah, but this problem is solved by the code review/pull request process! I see the changes that you make to code and to tests at the same time. If your changes aren't tested I don't merge or you have to have a good reason for why they aren't being tested.

Don't buy it. My general flow is: Build something small, write tests to test the thing I built, test the thing I built in the app. It doesn't take long doing this to realize how you need to write code for easy testing. Not to mention the vast majority of things that are needed for easy testing are just standard good ol' development practices.

Funnily enough I don't consider this a knock on TDD because it seems like its just a knock on automated testing in general.