Slightly Less Awful Hiring for Engineering Talent
codeforamerica.org
codeforamerica.org
I'm curious if anyone else sees that trend, or if I'm just making it up. One of the reasons is that several friends of mine have been bugging me for a while to help get them started with code. These are people around my age. Professional musicians from back in the time of my life when that was what I did for a living.
There five of them now who have been asking, so I'm finally putting together a structured curriculum and working with them on a regular basis. When we get done in six months or so, they will have some abilities with Linux server administration, databases, Python, C#, web application frameworks, javascript,front end work, version control, and testing. I'll work in some CS theory as we hit appropriate points.
Obviously, they will be very green. But they are all incredibly bright, professional, adults. One of them has a master's in Math she got after her Doctorate in music just because she was curious, and another has most of a PhD in Physics. I don't think any of them expect to waltz into a high-powered job after 6 months of me spewing at them. But I think any of them would thrive in a junior position with people around them who had the time and the inclination to do some mentoring.
Are those kinds of jobs disappearing? Am I being unrealistic hoping that this could be an option for some of them? What do you think?
I guess an anecdote but managers at my company don't hire entry level developers because they don't want to pay what they can ask for and don't want to wait for them to get up to speed.
The irony is when a senior person does come in, all their recommendations are ignored because they will slow down the pace of development. Which it will, but in exchange for setting a sustainable pace of development. A senior developer might (making numbers up here) crank out 100 lines of code per day, but a junior will crank out 1,000 while solving twice as many business problems. Unfortunately, bug counts seem to scale linearly with code size, so most of the problems you're solving are actually just a direct consequence of the ten-fold increase in bugs in the larger code base. Eventually progress grinds to a complete halt as it becomes too difficult to add business value, and the company enters zombie mode where its death is virtually inevitable, but can still operate for years through additional funding.
Sorry, I may have gotten a little off point there.
The CEO of the business will basically hear two messages:
1. "Look at how well my tech organisation is doing, we solved 150 tickets this week, a 40% increase over the last 3 months! And yet our headcount only increased 10%."
2. what your comment said.
It's down to him to act accordingly. I've seen many trust 1, he's "data-driven".
There's variations of the JIRA ticket inflation, such as requesting regular update meetings and the tech organisation adapting by finding days-long tasks and pushing off the hard weeks-long ones (since they do not result in neat weekly progress updates).
"I've listened to all the excellent argument for doing nothing, and reaped the consequent frightful harvest. I've watched people hop up and down and call it progress." - George Smiley (in Smiley's People) making the point that this is not a new problem.
Every time someone suggests we have proper requirements or decent testing or put some thought into design or rewrite something that's causing endless trouble, we're told there's no time for it.
Which is how we're now up to "release candidate" FORTY, four months behind the original release date. Because tests get done six months after the code was written, whatever doesn't fail has a fifty-fifty chance of not actually doing what's needed (so it's a bug), and testers and coders have long conversations about "what's it even meant to do, anyway?" that are unanswerable because there is no requirement or design reference.
The cost of running four months over schedule thus far is, well, four man-months multiplied by the number of employees, basically. So yeah, excellent savings compared to having spent a couple of days thinking about what we're trying to build and having testers involved throughout rather than just dumping six months' worth of untested development on them (and expecting them not only to be able to test it in a week, but expecting everything to pass).
Wouldn't mind if this was the first time, but EVERY DAMN CYCLE is the same. We can't possible start doing things properly, look how far behind we are! It's like there's a mental gap, some kind of inability to see the cause and effect right in front of their faces.
( Morale is low :p )
I should point out that as professionals not only do we have the option of saying no to bad requests, I think we also have the obligation to do so.
I know there's this culture in software development of "just do whatever the bosses say", but as far as I can tell it's not a law. I've told executives no on many occasions and so far I've never been fired for it. At first their startled, but if you keep saying no to the bad requests and help them understand what they're supposed to do, they eventually come around. And if not, this is an excellent time to find another software development job.
> It's like there's a mental gap, some kind of inability to see the cause and effect right in front of their faces.
Yes, that definitely happens. Until people experience it the other way, they often think that's just how software development has to be.
Indeed. I watched three people say "no" to a significant, new piece of very important software that replaced completely our legacy data storage/fetching/processing methods. They said "no" for the reasons you'd expect; not properly specified, unreasonable expectations of basically magic on the part of management, very improbable timescale.
In one meeting, when a very skilled programmer (who goes to the C++ committee meetings and that sort of thing) said "no", the response was "Well then I'll find someone who can." What they got, of course, was someone who didn't say "no" (and of course, there's an element of self-selection here; given that some skilled, competent software engineers said no, the person who said yes was, harsh as it may sound, an adequate programmer but an incompetent software engineer). What we got was a total car crash of software, six months late, that's massively unsuitable, doesn't do what's needed, undocumented, untested, everything bad that you'd expect. A great deal of the 40 "release candidates" were desperate fixes to this car crash, that our recently appointed new software architect is planning to take outside and execute in the car park as soon as we get a "release". So that was a great use of a year.
Where this is going is that saying "no" didn't actually stop them finding someone who wouldn't say "no". On the plus side, the person who delivered this truly atrocious software to us is now actively looking for another job. Not that he was fired, no no, but he's now got zero credibility and nobody wants to work on anything he ever touched.
Christ, I wish I'd just gone into mathematics.
It's also a problem for me because he's done his damage. I want to make high-quality software, on time, that does what the customers need. I want this out of both a sense of personal pride, and also because I need the company to keep making sales so they can keep giving me money.
I am bemused that someone of your experience has trouble grasping this. I thought perhaps you were some kid straight out of school who thinks the whole world works like the marketing material for agile, but it turns out you've got a decade of experience. You must, surely, have seen (or at least heard of) companies that don't look like the marketing material for agile?
When people started asking for my help, I couldn't think of one particular resource to point them at that would give them a wholistic idea of the things I've experienced to be important in my career.
I don't mean this as a critique to any of the fine programs out there. Many are very good and have been valuable to me.
I do plan to make my course of study available online. I'll be getting feedback from my friends as we do this, and that will adjust some of my choices.
To use a personal illustration, at my old job I had a group composed of about 85 programmers, 15 QA, 5 devops and 5 DBAs, with a few miscellaneous non-tech people (PMs, analysts, etc). In that situation I was perfectly satisfied hiring junior folks with only 0-3 years of experience but a good head on their shoulders and a desire to learn, because there was enough slack in the larger org to make up for temporary slowdowns resulting from training & general learnings. In my current role, I have a team of a half dozen, 4 of whom are skilled analyst/PM types. If I want to build something, I either have to outsource or hire one of two of the very best "full stack" developers that I can trust to throw anything from front end design to web + mobile dev + data structures & reporting/analysis on the backend. As a result, I'm almost always searching for people with 10 years of industry experience who have spent all that time learning & practicing a diverse set of skills.
I think one thing that'll cause disappearance of low end jobs is the upcoming/increasing automation of business processes using click & drag workflow platforms (and better leaner ERPs & CRMs). My previous employer has about 200 IT people just keeping Oracle running, and another 150 or so working on manufacturing software. I think the majority of those kinds of jobs in big enterprise are going to disappear in the next 10 years... and that's A LOT of jobs. Fortunately, one of the triggers will be retirement of boomers, so it'll be a more natural progression than massive layoffs would be.
So if there is a smaller number of positions advertised, I think it's just because they don't have to advertise to find junior people. But personally I'd encourage you to teach your friends, as my hiring strategy in the future is to build teams that are really good at taking junior people and leveling them up.
I suspect that most "rockstar ninja" positions actually end up being filled by people like what I was when I was 17, by which I mean, smart kids who aren't afraid to bite off more than they can chew, who don't necessarily know nearly as much as they think they know.
So yes, if I'm right, entry level positions are still there... you just have to convince them that you think you are a "rockstar ninja" (I like to think I'd be embarrassed by that, even at 17... but realistically? 17 year old me would probably eat that shit up.)
When I was working in finance, on the other hand, I likely would have put the salary in if we had enough size and data to give firm salary bands.
But do indicate language in the nice-to-haves at least. Some programmers find that they work much better with certain tools than others and it is useful to know if you are able to use those tools.
I'm curious. Are there projects/organizations anyone can think of that were in this position went on to success?
I have a suspicion that by the time an organization gets itself in a position where it needs a dev with niche skills and the need is so urgent that it can't spare even two months to get a top generalist developer up to speed... it's already made some bad decisions that might mean that it's not going to survive.
Highly specialized knowledge directly in the product domain is one thing. That's understandable. If what we're talking here is language/stack preference, that's something else.
It is however relatively unique to Haskell and similar languages whose paradigm is very different to what most of the market is used to.
Everything is an optimization over a number of variables.
The upside of Haskell is that (if you make an effort) you get very good people and they don't cost as much because there is comparatively less demand for the language, so even on a greenfield project it makes sense to give it a shot. This is aside from numerous language-specific benefits which have been discussed to death in the never ending language wars.
The downside is that only a portion of the self-defined Haskell community can truly be more productive in Haskell than say, Python; and these people have many options and are themselves making trade-offs and optimizing across a variety of variables when picking a job (e.g. interesting machine learning work in Python vs boring CRUD work in Haskell, given the same salary, might rank about the same). If you find these people, if they want to work for you, you get good results. But you're bidding against Google and hedge funds, so you need to find an edge that they cannot take advantage of. For example, I saw almost no CVs with prestigious universities on them, because that's a common filter in prestigious organisations, who tend to miss out on the self-taught talent and the less well ranked alumni; those with "prestigious" CVs wait for organisations to get in touch rather than having to sell themselves. So it's probably a good idea to avoid using university as a filter.
One reason there are many Haskell job openings in comparably fragile settings (low budget, bad politics, low stakes etc.) is because in cases where resources are ample (thus allowing for time for senior people to learn a new language or junior people to learn professional software development skills), the risk-taking appetite is less and managers will hedge by going for the popular instead of taking a "Python paradox"/blub bet. A cynical reason for this might also be that you do not want to be dependent on a small number of talented people - having a large team of replaceable junior talent hedges against the developers acquiring strong negotiating power by virtue of adding too much value, or even just the risk that a car crash wipes out half your codebase.
In some ways the survivability of the organisation in the low-resource setting is then dependent on the Haskeller - if you help your employer increase its conversion rate or customer lifetime value 10-fold, or reduce dev ops and infrastucture cost by a factor of 10, you might well change the very dynamics of the business and justify your team and salary; so it might make sense to take a less attractive posting if you know this is a possibility. At the same time, there are numerous companies arguing this to try and get you to accept a pay cut.
https://www.codeforamerica.org/about/fellowship/
That's a great opportunity for people with a few years experience to stretch themselves, being part of a small team that has a year to research, evolve, and deliver a whole system.
Recently I spent some time interviewing and jumping between jobs, and compared to the amount of time I spent working at one company, I was spending a lot of time interviewing, preparing for interviews, and applying to companies.
Basically, my impression from being a high school programmer was walking in the door, being qualified, and being hired essentially in the same afternoon. After getting through college, it seems to be way more of a contest to win a job.
Similarly, I earned an internship at a high-profile company in New York City, which I didn't actually complete due to extenuating circumstances, but the impression I had from the interview and from a few days on the job was that the role was trivially easy and they were somehow scouting the absolutely most qualified and talented programmers in the country, anyway. This might happen to work out but something seems broken in this situation, too.
In this case, though, this team had only one position to fill and hadn't hired together before, so we needed to see a fair number of candidates in a batch so that we could collectively calibrate. That took more time than I wanted.
I definitely don't think we were too selective, though. Good developers can quickly improve both a team and a code base. Bad ones can harm both in ways that are expensive to fix. I think a lot of typical selection criteria are bunk (e.g., fancy schools, fancy companies on the resume), and I'm not always looking for amazing technical qualifications. But I definitely think it's worth time to find people who are great fits for the job.
You state that "a good programmer can learn a language quickly". I think most people who have experience with hiring developers disputes this. Learning a language is also one of the easier hurdles to overcome when moving into a new programming domain.
If you're hiring for a Ruby on Rails team, and you want to hire someone who has prior experience as a developer but has never touched Ruby in their life, you're probably not going to be too worried about how quickly it will take them to learn Ruby. The real challenge will be learning Rails, and then becoming proficient enough to work alongside the current development team and the pre-existing codebase.
Also, how do you approach hiring for mobile? That seems like a domain where language is important, since it's tied to the domain if you plan on native development (which you should). If you're hiring for an iOS position, are you not going to prioritize a candidate with prior iOS experience over one who has only done Android?
It's difficult for me to imagine a scenario where you would have to resort to a former Android dev unless you aren't willing to pay a fair hourly rate or salary, and you're going to bargain for the opportunity to learn in exchange for lower pay.
As to the mobile question, it would depend on the team composition. If I'm hiring the first mobile developer, then yeah, I'm going to look for somebody with a lot of experience. Probably the second as well. But for the third and after, I wouldn't put it as a requirement. As long as there are people around who can mentor, then I'd rather hire a strong developer with little mobile experience than a not-so-great developer with plenty of mobile experience.