Hire Literally Anyone
arches.io
arches.io
I worked at a company that couldn't find DBAs in the late 90s for a reasonable salary. They would pluck kids too smart for call center work and put them in database apprenticeships. They deal with support cases, do drudge work fixing data problems cause by one of the applications, investigate chargebacks, etc. 4/6 that worked for me are all high end tech folks now.
Another example was a .gov stuck with secretaries rendered obsolete by MS Office. They offered training and transitioned many to IT roles, mostly in training, sysadmin and business analyst roles. Most of them did great, one I knew 15 years ago as a junior training person is now a director of a big erp implementation.
I've done both of those jobs and they've both required me already knowing how to code, writing code, and having a CS degree. I think it's sort of ironic that he manages to devalue the very same non-software engineering skills he ostensibly says to value.
All of this for only 90k, in silicon valley?
The coding work I'd put in the "internal tools/analysis" category, such as writing some scripts which makes sense of the non-technical PMs' spreadsheets, browser plugins which deal with a favorite but slightly broken tool, log analysis, writing dashboards, or lightweight ETL.
The "knowing how to code" comes in use since a fair amount of the work depends on being able to understand what the devs have actually submitted and if they are flat out BSing or not on status, if a particular pattern/integration/library/tool would be a good fit, or having meaningful conversations about testing, scope, and technical roadblocks. The CS degree is useful for having credibility with the devs(shared culture goes a long way in getting work out of people who don't report to you) and not just being another PM having sprints and scrums and pigs and chickens and swimlanes (oh my!)
- It seems the author has some problem with technical people but they never state what the problem is.
- The author identifies that technical people aren't strong on "Problem solving, teamwork, self-teaching, communication, attention to detail, organization, etc." What the shit? These are exactly what makes technical people so strong.
Maybe the author doesn't like the terse and functional communication method used by technical people; but if they can't handle technical people or understand why we talk that way then they are the problem.
- "we need to value non-code skills much more highly and explicitly." They never explain why you want to hire janitors with mathematics intuition, or brain surgeons who can also tap dance; but if you're a programmer then you damn well better be extrovert! I don't care if you can code just give me a nice conversation about sports and cars. Idiot.
- "But resumes, interviews, the whole hiring process is set up to focus on technical ability."
Actually a very tiny tiny portion of Silicon Valley hires on extreme programming challenges. The 99.999% rest of companies all over the rest of the world hire based on how much they like you in the interview - causing much frustration for people who are highly skilled and eager and ready to go for some job but got turned away because they were brogrammer enough.
- "Hiring devs is really hard". What? How? Because there aren't enough? Because of some other problem? Just stating shit out of the ether doesn't make it true. A bit of introspection and elucidation would go a long way.
- "Can't code? GTFO." If you were an engineer you'd be told to GTFO. If you were a pilot you'd be told to GTFO. If you were a surgeon you'd be told to GTFO. If you were an accountant you'd be told to GTFO.
The only places that don't tell you to GTFO are fast food and strip joints. I can see the author holds IT skills in high esteem.
This article is a pile of shit.
The rest of this reads like "all these nerds should share their NERDMAGICK so us normal people can do IMPORTANT THINGS"
You claim that "The author identifies that technical people aren't strong on "Problem solving, teamwork, self-teaching, communication, attention to detail, organization, etc." What the shit? These are exactly what makes technical people so strong."
You may want to reread the first paragraph, because it AGREES with you:
"I have number of recent example of people . . . already SO strong on the non-code aspects of programming . . . Problem solving, teamwork, self-teaching, communication, attention to detail, organization, etc. "
Your other observations may have merit or they may be just as clouded as this one, so you don't seem like a very reliable source here.
If the author thinks that technical people can be equally strong in these people skills, then why are they advocating explicitly hiring non-technical people for the job? It's not like there's a scarcity of engineers that aren't total mouth-breathers. Just hire engineers that also happen to have good communication skills. You don't have to go to some absurd extreme of hiring incompetent people.
Also rubber ducking with the actual developer takes a lot of developer's time (and it's hard) - so the organization will take a big productivity hit if developers work half time as programming teachers. This is not realistic. Basically - non technical people must work extra hours (not have a life) with people who work full time training them to succeed. And the programming camps do this - but most non technical people feel the effort is not worth it.
I've taught non-developers to produce, or at least understand, basic code typically in a few weeks while they were working on other stuff as well, but teaching developers to be good managers has always been much more difficult in comparison. I think it's easy to assume that since a lot of people aren't interested in writing code, it's fundamentally difficult to learn.
I mentored few non-developers into becoming full time developers - but it took a year of their full time commitment to achieve the level where they could get hired as a developer and continue to develop their skills themselves.
But if you want to grow, it's not reasonable to expect to walk down to the 7/11 and get someone who is perfect for your company. Training is hard? Growth is hard. Who promised you that running a business would be easy?
Just in my city the last two months I saw job openings for two different companies trying to organize people giving away stuff for free, and neither of those companies were Craigslist, Freecycle or the Buy Nothing Project.
On each project I've been on I've spent upwards of 20% of my time recreating a variation on software I had at another job, and I think I care more about reuse and force multipliers than the vast majority of people. And when I'm using libraries, I feel like I'm working a lot harder than I should have to.
Fred Brooks claimed an Amdahl's Law style effect with additional programmers, and I don't think he's wrong (at least not about that). If everyone on a team of 10 started needing to do 10% less work, we could just about put off hiring two more people to complete our deliverables.
Where I do think he's wrong is his use of a Surgical Team as the ideal for programming. One person in charge and a bunch of people assisting. I think that given the world has largely rejected that section of an otherwise brilliant book, that people generally agree with me that Fred had this part dead wrong. I think rather we should work like professional athletes do in team sports, and we would get about 3 times better at what we do.
I was a cyclist when I was younger, and for a time it was popular for pros to write books or articles with advice. I was surprised to learn that a professional athlete isn't crazy better than me at any one thing. It's the fact that they're 20% better at half a dozen things (including genetics), and the multiplier makes them be able to go twice as far and half again as fast. Dedication, mastery, and a small team of people looking out for them, not just mutant genes or dumb luck.
As programmers, what do we study to raise our game? How computers work. To me this is like a quarterback or a sprinter learning how cleats are made to make him a better, or a cyclist how carbon fiber frames are built. Did I do that? Sure, and it's useful, but not as useful as understanding how your own body functions. By comparison computer programmers know almost nothing about how human brains work, and all of our output comes from them. We don't even have our eye on the target.
Basically, to be a professional athlete, you have to understand human physiology to a degree most people know nothing about. You have a team of people whose job it is to explain it to you and keep you working well within its limits. Do athletes get better by gritting their teeth and keeping at it? Sure, that's only one part of a greater whole. If you listen to some developers, that's all we need to do. Tough it out, white knuckle style. Effort measures all. People who complain about how the design of the code base makes it hard to remember are invalidated, called whiners or told to sack up.
As long as that's our pattern we'll never raise our game much.
2. We already hire 'anyone' by hiring people from 3 month coding boot camps which are usually pretty cheap in price and time compared to college. Passing a coding boot camp or showing self developed apps & their source code I feel is the reasonable compromise for hiring 'anyone'. There is a segment of the population where programming is not for them and learning to pass fizz buzz equivalents is a lot more work for them than others.
Oh my.
Anecdote: next to my Information Science studies, I worked as a community manager for a few years. This was at a small startup so I was in practice doing more than that (marketing, data analysis, QA, etc). Once I finished my studies my CTO asked me to become a developer - he knew I was dedicated to the mission, knew just a little about coding but had the right personality for it. Sadly, in the end they realised that they didn't have enough time to train me and had to withdraw the offer.
I think it would be great if more CTOs made such offers, though in practice it seems unlikely. Small companies are less likely to have the resources to train and in larger companies perhaps the CTO is less likely to know community managers and such well enough to make such offers.
I spent much of the past year helping interns who were college students, some of them freshman, learn a new programming language. I think that isn't ideal for a variety of reasons, but instead of hiring one junior person at $90, hiring 3 near programmers at $30k could work well. (Though that last bit is a dichotomy-- it wouldn't be either or, it would be both-- if there are good people, hire them, whether they can code or not.)
I personally did very well there, went on to a financial services startup of all folks who'd left said bank and then branched out on my own doing web applications for clients and building a successful open source project with millions of users. I'm not sure if I'd get through the modern code-in-front-of-us-at-a-whiteboard approach that all the tech companies seem to favor now-a-days.
If you can develop a system to where a few people are essentially "trainers" (or some degree) this could work out exceptionally well...or fail miserably, I'm not sure which yet.
There's no inherent reason this model can't work with untrained, not-yet-technical non-interns. You just need to set up explicit expectations: this is a temp job (3-6 months long). The top 30% of people will be given a 3-6 month extension, during which they'll do real coding work alongside current engineers. The top ~30% of those to be given full time offers, at a "new grad" level, based on whether, by the end of the last month, they were operating at a "new grad engineer" level.
There is plenty of precedent for this, during the dotcom days and in India the last 10 years.
What happens if we invest in our people and they leave? What if we don't, and they stay?
I've known plenty of master programmers who could tell me nothing about mastery other than 'train hard, train long'. I think actually this comes from 'sacrificing' everything else in life to become good coders at a young age, and we don't take the time to see what mastering other skills looks and feels like. I call it "Master of one, master of none."
Every time you teach something you should get a little better at teaching it. Your materials should get clearer. Your understanding of the material should improve. At the end of the day you and your training material are better for having had the student, even if they bail on you just when they're getting interesting. But if you respect the student and the exercise I don't think you'll have that happen that often, unless there's something fishy going on elsewhere in the organization.
Conversely, I think going off and earnestly learning a martial art, cooking ('mise en place' is a concept every coder should know), an instrument, or Chess or Go, or preferably at least two of those, will do wonders not just for your coding but for your personality. First, you will have to get comfortable with being bad at something again. Then you will watch yourself think you have something figured out, and then the teacher will tear it all down and build you back up at a new layer, only to tear it all down again a year from now. Watching that rug get pulled out from underneath you over and over again makes you start wondering what other things in life you're comfortably dead wrong about, because you believed in a colorful fiction that was 'true' for you where you were but is not the objective truth. And maybe the objective truth doesn't matter because it benefits almost nobody anyway. There's just where you are and where you're going.
This is a good thing. INTJ and other Meyers-Briggs types have no basis in science and they aren't related to what work a person can do for a business.
Wait WHAT?! How is that bad? Who does this benefit other than people that want to do a job that they're not actually qualified for? "Can you do this thing or not" is a pretty fair test of if you deserve the job!
An apprentice goes to a coding bootcamp, paid for by an company with a $2,500/month stipend. Then, the apprentice would work for the company for $2,500/month for one year, or otherwise the coding bootcamp tuition must be repaid.
This would work out to a cost of about $55,000 for a year of labor.
That would be significantly cheaper than hiring a coding bootcamp grad, and removes the economic risk from the apprentice. What if the market were to soften? What if they ended up being one of the graduates that could not land a job?
This offloads a lot of training to the bootcamp, which have job training as their core competency. Other commenters have pointed out flaws with the system proposed by the author.
In addition, it generally aligns incentives so that the apprentice is less likely to leave right after the initial training. As part of the deal, the coding bootcamp would help the apprentice with finding some other job, since they have already committed to an employer. If they did renege on that part of the deal, the employer only lost out on $7,500. And once the apprentice proves their worth (in the event that they do), the employer could offer a market salary that would start after the apprenticeship, along with a signing bonus of about $20,000 or so. The apprentice would probably want that signing bonus immediately, and sign that offer unless the candidate disliked the company.
If anyone wants to kickstart this concept, I think this would make a great nonprofit. Figuring how to implement such a program would be a distraction for the company, especially if they just wanted to dip their toes in the water with one apprentice at first. The nonprofit would get $10,000 per apprentice, and additional donations by companies could lead to higher priority in selecting potential apprentices.
"They did things differently than everyone else. Most of the company used an esoteric programming environment called Rosie SQL - which seemed like death to my Demo Szene honed sensibilities (Assembler, Pascal or bust!) - these guys used Delphi."
MathWorks is doing a similar thing to
"The first 3 months in the cafeteria meant I quickly met everyone in the company and learned what kind of coffee or tea they liked."
Mathworks starts everyone off in support, to make sure they know the products and the customers.
Also the explicit discrimination based up on how represented applicants' "communities" are being recommended ahead of looking at actual technical skills is disturbing. I don't think it's illegal, but I also don't think it's good business or ethical.
Honestly, this kind of rule is how schools like Harvard keep low numbers of Asians (or in the past, Jews).
Doesn't this, and most of the other stuff this is talking about really refer to project managers and people managers?
It works out surprisingly well. The 2-3 experienced devs and myself do the harder development parts and the new developers are actually quite valuable as they contribute plenty to the code but also often explain some of the business considerations from other departments.
You wouldn't want to have the inexperienced non-tech people making critical engineering decisions. Software development is like building a house of cards - If you want to build a tall structure, you have to start with a solid base.
The people who seemed the sharpest in the first two weeks of training usually excelled, most others didn't. Some were simply unable to learn fairly basic concepts. It mostly came down to raw intellect. I'm sure the same would be true for aspiring developers.
Did you ever take the SAT / ACT?
Please don't ever do this.
Are applied sciences grad programs not "creative work" in your mind? Standardized tests statistically predict success within those programs.
http://portal.scienceintheclassroom.org/sites/default/files/...
In short, throw people out for almost any reason you want, and HN will defend your right to do so. But suggest that we could ever choose employees based on measures of "intelligence" or academic performance, and you are obviously doing something horrible and nobody should see your post.
There's at least one good thing about standardized testing: at least it's standardized and objective rather than being based on vague emotional criteria - how well you can con the interviewers, or whether they think you're just like them, or whether you present social proof that you convinced sufficiently many other companies in the past, or whether you are literally a friend of an employee.
No way. All those reasons you mentioned above you've really seen people on HN defend those without being downvoted? I only ever see HN against many of those items of discrimination you mention...
> There's at least one good thing about standardized testing: at least it's standardized and objective rather than being based on vague emotional criteria
Except they're not objective but you're right they are standardized. This is not a good way of measuring people for many reasons. The more importance you put into standardize testing the more you get teachers teaching only the content contained within and you put more weight against a teacher's grading styles (which can vary wildly even on standardized testing when they're graded away from the school).
Standardized testing probably has its place but as criteria for employment is laughable at best.