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.
As a DBA I think if you have an installation of considerable size you really absolutely need one of those high salaried people. The rest - sure have juniors. But there is a reason people with a lot of experience demand a lot and that's because all of the little things we know make up for a lot of improvements and help when things go bad.
Growing people is doable, but takes time, a lot of time. If you are running a big company and can afford to the spend that time, it's great, but for small companies it's a recipe for disaster.
I like how he assumes that test engineering and project management are things you can just "fill someone's time with" until they learn something useful, like coding AND that someone will take 30k a year for. Really? In the valley, both test engineers and PMs for software eng projects are >90k/year positions.
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.
I find it pretty odd that you'd take a PM role that required you to write code and have a CS degree. It's definitely good if PMs understand the technologies they're working with, but requiring they know how to code, and actually code, as well as have a CS degree seems like an employer who is actually looking to hire a developer and get a PM for free. Or vice versa.
Specifically, regarding the PM role, I took a TPM role. I like it much more than devops/sre(no pages) or test engineering(not as tedious). To be sure, there is also a non-technical PM on my team, as well as devs who do the product coding. While the role could be abused in the way you are talking about, I suspect that's company dependant, in much the same way the devops role can be abused.
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!)
If you look on glassdoor, that's around the jr/entry level base salary for both positions, mid/senior level PM and test engineers both are more. Since the article's claim you that could get this work for 30k from someone on their way to learning how to code is extremely off for the entry level, I didn't bother with how wrong it is for the mid or senior levels.
Wow, what a crock of shit. How did this get to the top of HN?
- 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.
I read your post before the article so I expected something completely different. You're clearly reading this article through a very interesting lens.
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.
I got the impression from the article, like the parent post, that the author thinks these skills are more prevalent outside of tech. Why else would he suggest hiring for this above all else? Does he think that it's impossible to get people that are BOTH good communicators and solid engineers? These people aren't unicorns! I'd say the vast majority of coders I've worked with are totally fine at soft skills.
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.
Just don't understand why software devs tend to devalue their own work and skills as if it is something anyone can learn in a few days or weeks. I mean it is easy to start but very difficult to master.
It's classic, this person clearly does not understand shit about engineering, so they move the goal posts. "Oh its all the non engineering personality factors that are actually important... not like uh, what you can actually build... teamwork!"
The rest of this reads like "all these nerds should share their NERDMAGICK so us normal people can do IMPORTANT THINGS"
Teaching people to develop software is hard.
It requires commitment. In the framework author is describing if those people want to succeed they will not be able to do it part time while doing non-technical work for you.
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'll offer a counter-argument that teaching non-technical skills is at least as hard as teaching basic development skills. You just generally get more years of "free passes" to develop non-technical skills (ex., negotiation, conflict resolution, self-management, etc.) on the job than you do if you're expected to be productive doing technical work.
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.
Well - I consider teaching non-technical skills even harder. That fact does not make teaching programming easy.
Author is trying to solve problem of developer shortage. There is a huge gap between "being able to produce basic code" and being a developer that can solve a class of problems by him / herself.
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.
If it is too hard to train anybody, if you don't have time to train anybody, that's okay. Just don't hire, and make sure you retain your current employees.
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?
There is no shortage of developers. There is a shortage of perfect developers that meet every preconceived notion of lazy companies that don't believe they have any responsibility to develop and grow people. There will always be a shortage of top performers in any field. If only top performers are acceptable to you, you will have a very tough time growing. I have to laugh when I see these posts where people have 'discovered' that you can actually train people to make them better. I saw one a few months back where the 'secret' to using bootcampers turned out to be 'provide a guided program to finish developing their abilities', as if no one ever heard of this before.
There is a shortage of cheap developers. In a Taxi in Dublin a year back and the taxi drive explained his friend couldn't find the staff. "Well he could, but they wanted too much money".
I turned down a job a year ago because the pay was 20% below expectations, and saw the company in the news a week later talking about the shortage of programmers.
There's also an oversupply of companies trying to create essentially the same product. If we could cut back on that we'd have a glut of programmers. It's just a bigger version of the work expanding to fill the time budget.
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.
1. The industry interviews this through 'culture fits'. Personality is not something your can put on a resume very well, it comes out in culture interviews. You need to pass personality and a technical bars in most interviews.
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.
Like most interviewers are skilled judges of 'culture'. This is why most tech companies are filled with bros telling themselves how cool they are and how they are changing the world. Utter BS.
Microsoft used to have a one year program for new grads that hadn't taken CS, called TAP. I knew some good devs who came out of that, its a real shame they scrapped it.
I feel like many companies are afraid to do this because there's no guarantee their newly trained people will stay for so long as to make it worthwile. What if instead of "literally anyone" they trained non-technical colleagues that have already proven commitment?
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.
Good developers aren't trained, they are self taught. This can be on the job. I would be happy to pay people who aren't quite yet developers $30k as the article suggests, and then mentor them.
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.)
That fear is unfounded and is a good example of short term thinking. My number one goal now is to make sure wherever I work the people I work with "level up" in some way. I'm going to be working with these people at other jobs and if they suck then I'm not doing anyone any favors. Having proper mentoring and training pipelines are indicators of a healthy company. The alternative is companies shuffling mediocre workers amongst themselves which is again not doing anyone any good.
When I was starting out right out of school, the corporate bank I went to work for had a 3 month program for recent grads to teach basic programming and database design along with company coding rules. They had non-coders in this program and started from scratch. Some of the folks in it with me were English majors. It was very successful and everyone in the program I kept in touch with went on to great careers. You interviewed for the company with round-robin interviews where 6 different department heads would have a sit down interview with you one at a time throughout a day. There was no coding involved.
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.
That's fine, you do that, but I do not want to be an engineer at your company. I already have a junior engineer I'm working with and it's hard enough spending hours a week making sure their PRs get fixed, every PR has 20 to 40 comments in it. With someone who doesn't even know how to code? Forget it.
I think that's why the OP suggested a pay scale but obviously you wouldn't want to do this unless you can setup a system of on-boarding so you're not killing other developer's productivity.
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 a way to make this work, that a lot of tech companies already do with not-yet-technical freshman and sophomores in college: give a large funnel of people an actual training course a few months long. Give the best of this large funnel return internships. Again, give them some amount of training but this time more real-world experience. Those that actually helped the business, give full time offers to.
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.
It's a great idea but the reason why this won't work is because after you have invested time to train them from nothing, they will leave for another company.
There is plenty of precedent for this, during the dotcom days and in India the last 10 years.
Exactly this, people leave for other reasons and generally it isn't because you're investing in them. Sure it happens but it isn't the usual case in my experience.
It doesn't have to be that bad. There's an old bit about the teacher learning more than the students.
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.
A good rule of thumb is that if a model of humans asserts that we fit into an enumerated set of "types", it's probably either substantially incomplete or outright pseudoscience.
> We desperately need new paths to success and we desperately need to lower the barriers to entry. Our current approach is so black-and-white. Can you code? Here's $70k+. Can't code? GTFO.
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.
Do keep in mind that the author already knew some programming before he started his apprenticeship:
"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.
I don't think the author's suggestion of hiring people to "just sit there and watch/talk with (senior devs)" for 30k/year makes much economic sense.
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).
While I agree with this, and have been training someone in this manner for a while, it does put a drain on the trainer, and you have to take that into account, as Fred Brooks wasn't wrong...
I'm a self-taught career changer and work for a team that has several new developers transferred from other departments.
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.
one of the best ways for someone who wants to start coding is to join a smaller technical company as customer support. You'll know the product intimately and you'll know how to improve quality of life for users. If you're motivated enough, start talking to engineers and contributing to the codebase and you're on your way.
Hiring non-technical people into technical roles is OK if you also have some senior tech people to guide them.
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.
It seems makersquare's financial assistance works to solve the boot camp pain point mentioned, and with a programming job salary after, it shouldn't be bad paying it down.
I think we should do this with medicine as well.
Hire literally anyone and train them to slowly take on the tasks of a medical doctor. The theory and focused study that comes from a degree is really overrated. This would really help with the shortage of doctors as well.
"Hire anyone with decent standardized test scores," would be my baseline after managing a large, technical support callcenter where many new hires were simply not able to learn the (imho fairly rudimentary) modem troubleshooting steps after weeks and months of on-the-job training and support.
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.
Don't count on it. I failed out of college due to my inability to take and pass tests, yet at work, I'm being promoted constantly to higher ranks due to my productivity.
Considering I managed literally thousands of agents over a period of years, you would statistically be an extremely rare exception to a rather well-examined trend.
Source? It's all anecdotal but I know far, far too many great developers who never even took the SAT (or did horrible on them) and are wildly successful in their careers. I have a hard time believing this is "extremely rare" especially considering most colleges now don't rely on them to a large degree.
It is okay in the industry to discriminate employees based on whether they just graduated from a top tier school like Stanford. Or whether they have years of experience at a top tier company like Google. Or answer absurdly irrelevant puzzles, or implement red-black trees from memory on a whiteboard. Or whether they can answer aggressive questions demanding to explain their business value. Or whether they are a "culture fit" (too black, too old, too female, etc.) Or whether they have enough names of technologies you use in the resume. Or whether their resumes are well-formatted.
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.
> In short, throw people out for almost any reason you want, and HN will defend your right to do so
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.
jsnell is right—that's excessive. HN threads are supposed to be conversations, not commercials. There's nothing wrong with telling a story or mentioning one's own work in context, but please don't do repetitive promotion.
I honestly try to add value to the HN discussion and I usually get upvotes. At the same time I often mention my recruiting thing. I agree that this post really went to far. Sorry this won't happen again.
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.