Then the hiring firm is a group of fools best avoided.
Tools change like fashion. What is "hot" today will be nearly frowned on in 5 years and forgotten in a decade or so. In 20 years the fundamentals still matter, the tools, not so much (Pascal? Powerbuilder? Win32 in C?)
A smart developer can learn any tool. Hire for aptitude, not today's toolset.
I agree. Of course, there is a "spin-up" time and we prefer to select the competent candidate with skill in our tools vs the competent candidate with skill in a different tool; but absolutely a competent developer should be able to adapt to any environment.
Interviews can help accommodate this by allowing the candidate to solve a coding test in a language of their choice, while also inquiring about the candidate's learning plans. (Want to make sure they are willing to adapt to the team's tools and not try to force the team to adapt to them!)
I took a job once where the code base was in a FORTRAN-derivative language. I had never used FORTRAN or anything like it. Not a problem. I studied the code. I studied the docs. I figured it out and did the work. I would expect nothing less of any other competent developer.
Another job had a toolchain based on NodeJS on the server-side. Never used NodeJS. Not a problem. Studied the code. Studied the docs. You know the story.
The key skill is a developer's willingness and ability to learn the tools that are desired for the job at hand, and to accept and learn new tools when the time is right.
Isn't the point of an internship to continue your formation ? How comes companies making the same tests as for recruiting for real jobs ?
"Hi, we are not going to pay you, or not very much, but please be at the same level as senior that are already working for us"
I had interns back in the day I had an office (and not working from home) and I always made them work on basic tasks under my supervision. Once I had one woman who was very good, and she worked on a website that ended in production, but most of the time the purpose was to work on internal projects that can be used even if not perfectly polished. You know, stuff you always say you're going to do some day, but you don't.
The advantages were on both sides. They learned real life cases, under my supervision, and I had the tools I didn't.
Disclaimer : I'm French so maybe my example is not relevant.
We give coding challenges to our intern applicants, and most fail. We give different challenges and expect different levels of competency for a senior role.
Code challenges at least have the capability of being very useful. We try and present the type of problems people will have to be solving in that position; if they struggle with it and someone else excels, they have done their job.
>How comes companies making the same tests as for recruiting for real jobs ?
1) Because desirable internships have more candidate applications than available slots. E.g. Google has 40,000 students wanting an internship but only 1500 slots.[1] With that supply & demand ratio, Google can be selective via difficult coding tests.
2) Even though internships are unpaid, companies evaluate interns to potentially offer permanent employment. If so, a company like Google would want to fill those 1500 slots with "the best" rather than randomly pull from 40000 candidates.
That's how it is at the hot tech companies. Maybe other internship programs outside of tech sectors such as Peace Corps think of interns differently.
I'm sleepy, so I shouldn't post, but here goes. Confidence is really important for a programmer. Writing good code is very, very difficult. On the other hand, writing terrible code that barely works is not so difficult. There is a pretty big gulf between the two and if you don't have confidence that you can achieve something better, it is unlikely that you will even look.
Having said that, our industry is full of a lot of people who probably are not well suited for the job. Quite a few people look at the 6 figure salaries that you can get in some places in the US and figure it's a cushy way to get rich. Similarly, there are tons of jobs. Everybody is looking.
But here's the catch. "Everybody" is not looking for the average programmer. They are looking for the top 1% of applicants. Anybody who is hiring (i.e. everybody) can verify this. How man CVs do you get a month? How many do you interview? How many do you hire? And even then more than half the time I reckon companies are dissatisfied with the programmers they hire.
So there is actually a huge supply of average programmers that nobody wants. The average programmers aim at the "barely works" bar, and having hurdled it think they are senior programmers. A year or two under their belts, they demand their incredible wages.
At the same time, we all ask ourselves, "How can we protect ourselves from the hordes of untalented hacks knocking at our door?" Whiteboards, puzzles, trick-du-jour. It doesn't matter, because the real problem is what I stated at the top.
Confidence is important because writing good code is very, very difficult. Writing terrible code that barely works is not so difficult. We think we need to protect ourselves, but we don't need binary barriers to protect us from the untalented hacks. We need a better attitude. We need to realise that programming is a skill that takes time and effort to develop.
Some people should not be in this industry -- not because they don't have the chops; but because they don't actually want to put in the time and effort to develop their skills. And it is an overwhelming task. There is so much to learn that you will be drowning in it for years (another reason people put their fingers in the ears and think they are amazing).
So to any "young" programmers (of any age), my advice to you: Have courage. Have confidence. Love what you do because it's a crappy, horrible job if you don't -- no matter how much you get paid. And for those who don't love it... there are lots of jobs that are not programming, but are still in the industry. Quite a lot of them even pay more than programming! Seek them out.
> "How can we protect ourselves from the hordes of untalented hacks knocking at our door?"
And I think this is the wrong question to have.
"How can we get this new hire up to our standards?" would be better. Problem: once they're up to speed they'll be poached by a competitor. Answer: have real salary upgrades every-time some senior think they're better (not once a year at some review shitshow). Have a good working environment so when one of your people get to a competitor they only have good things to say about you. Then they may come back if things are not as good and may turn some of their new colleagues to send you their resumes.
That's expensive. But that's investing in your workforce. And this should be used not only for your coders but everyone.
I agree. It's not like our field is the only one with this problem, though. Take a look at professional football (soccer). There are a few teams that do not have an extensive youth program, but they pay through the nose for that oversight. Virtually every dominant team develops talent and secures them with good contracts. Of course, they have an incentive because they can sell players, which is unfortunately where the analogy breaks down.
And for those who don't love it... there are lots of jobs that are not programming, but are still in the industry. Quite a lot of them even pay more than programming! Seek them out.
Out of curiosity, what roles do you think pay more than programming? Product? PM?
Yeah that's what I was thinking - most anything that's going to consistently pay better than a direct development role is still going to require an understanding of programming. Outside of management roles, I've really only seen devops, product, and networking pay more than development (plus variations on these roles, or niche DBA/storage). Even then, it's not consistent, and in at least the devops role, you'll still likely be writing code every day.
Edit: Forgot about sales! I have a neighbor who works from home in sweat pants but makes insane money in tech sales. Though, he has admitted that the easy stuff is drying up.
As someone who has hired programmers, I cannot upvote you enough. Last time was less than a month ago. I interviewed everybody from junior to (presumably) almost lead.
During that time, I haven't met a single soul who would be able to describe what a call stack is and how it works, in rough terms. I don't have a CS degree, but I would imagine that it is something you would learn in the first year - I was tought it in high school (but have actually learned it much later, of course). Best that I got was a description of stack data structure and mumblings about how "variables go there and it's faster than heap". And the amount of bullshit that people came up with, looking completely confident, instead of honestly saying "I don't know it", is mind-boggling.
I had to look it up, once I did, I knew exactly what you were talking about, I just didn't know it by name. I was thinking about the process a request/response goes through via TCP/IP port. I've been doing this for 20 years. Maybe you need to rethink your interview questions. You are just testing for word/definition association which doesn't really matter outside of tech chest pumping. Perhaps explain what a call stack is, then ask why it's important and how it's used for debugging, etc. You shouldn't care so much about the what but rather the why.
I remember an old Delphi interview where they asked me what a I already forgot was. I didn't know by name, but once they showed me what they were talking about, I could explain it in depth. They ended up hiring me and I fixed their broken DSS engine and it ended up in a lucrative M&A.
Anyway, standard IQ tests have sections for various skills. Among the ones that are important for programming is abstract thinking and pattern recognition. You should be testing for that rather that word/definition association.
Maybe you're asking the wrong questions or are from an undesirable area. I mean the example question you're using is just trivia and not difficult to learn when a problem arises. I'm not sure how much more you want compared to "local variables, return addresses, parameters" tbh.
>if you don't have confidence that you can achieve something better, it is unlikely that you will even look.
This isn't true. The worst developers I know are also the most confident. They think their code is perfect the first time and they don't need to learn any more because they believe they already know everything there is to know. The more confident they are the worse their quality of work is. Luckily they are few and far between.
I'm not saying nobody should have any confidence only that having too much is very detrimental.
> Anybody who is hiring (i.e. everybody)
We aren't hiring.
> more than half the time I reckon companies are dissatisfied with the programmers they hire
Your organization has a problem. We've hired "duds" only a few times. The vast majority of the programmers we have hired have been just fine. Or maybe your expectations are just entirely unrealistic?
>So there is actually a huge supply of average programmers that nobody wants. The average programmers aim at the "barely works" bar, and having hurdled it think they are senior programmers. A year or two under their belts, they demand their incredible wages.
That has not been my experience.
> Love what you do because it's a crappy, horrible job if you don't
(My point was confidence leads to worse code, not better. In fact, "confidence that you can achieve something better" is actually really a lack of confidence.)
I agree with your points. It is curious to me that we've lost the idea of trade associations. I think knowledge work in general is fuzzy but whiteboard tests prove nothing. Degrees are becoming more and more meaningless. I wonder if there is a lack of financial benefit to having such associations.
>Some people should not be in this industry -- not because they don't have the chops; but because they don't actually want to put in the time and effort to develop their skills. And it is an overwhelming task.
This is something that is near and dear to my heart, so I'm gonna take the opportunity to rant on it a bit. There are quite a few high-paying and fast-moving fields.
Pretty much everything under medicine or law moves is moving on a week-to-week and even day-to-day basis, just like software development. Unlike software development, practitioners in these fields get paid to stay up to date, as part of their day jobs. Lawyers spend a good chunk of their days just reading the latest case reports that are relevant to their field, and boy howdy do our legal systems churn out a lot of reading for them to do.
It's pretty much only in software development that we expect professionals to stay up to date and develop new skills /in their spare time/. There would be a lot more 1% developers out there (or rather, we'd be able to look for the 5% or 10% rather than the 1%) if companies were willing to have their teams spend 4 hours a week training, but no one is willing to do that.
I have guesses on the causes of this industry-wide unwillingness to train, but one thing is for sure: this situation will never resolve itself as long as we honestly and unironically expect members of the field to spend their evenings and weekends learning new algorithms and languages instead of playing with their kids or chilling with their mates.
You know why so many developers settle for mediocrity? Because mediocrity pays the rent, and no one is supporting their path to excellence.
One of the advantages that doctors and lawyers have over us is that their field is no longer nascent. Their professions have existed in some form or another since ancient Greece, and were cornerstones of western society. We programmers have existed barely half a century, so we (rightly or wrongly) don't have that same sort of social gravitas. We also don't necessarily (some of us do) go through specialized graduate education systems to be a part of the field.
I guess I say all that to say is that people trust lawyers and doctors to be professionals. If they say that they need something, such as time to self-improve -- or the right tools, people listen. The respect their profession bestows upon them gives them an amount of personal clout that most of us don't get by virtue of simply being a dev.
>I have guesses on the causes of this industry-wide unwillingness to train
My current theory is it's at least somewhat a result of unions losing power. A union's strategy is to have as many people employed for as long as possible, so it's inherently a long term strategy. The better the company does long term, the better the union members are. I would say unions are the champions of long term strategy for self preservation. If the company goes out of business, all the union members are out of jobs.
Executives are more short term thinkers today. They want quarterly results and they have incentives based on those results (both quarterly and annual) and almost no long term results outside of accumulation of short term incentives. Executives also have the notorious golden parachutes which further shields them from the personal costs of short term thinking. This of course rewards short term thinking rather than long term thinking.
Training is a long term investment, not a short term investment. Short term thinkers want to find someone who will 'hit the ground running,' as I've sure you've heard. Ideally that's what anyone would want. The trouble is, that rarely happens once, much less for an entire team. Short term thinkers can't think outside of that strategy and therefore, we are where we are.
Every job I've had and encourages engineers to have reading groups, on any topic they want.
It's also my experience that most people ignore these opportunities
Is this also what others see?
Some reasons I can think are people:
- don't want any more meetings;
- are bad at having a merit driven discussion
There are very good reasons developers aren't encouraged to study on the job. The biggest one I can think of (that is especially prevalent today) is that not all studying results in usable knowledge, at least in software development.
Every verdict is effectively the new rules that lawyers will play by the second that it is made; you could lose the case for not knowing a specific verdict. Medical professionals practice an ancient field that has no interest in gung-ho, extraneous solutions to problems that have already been solved. Software development is one of the few fields where people working it think that learning some oddball, corner-case framework that got its start because the original developer didn't like the code style of some other oddball, corner-case framework is necessarily and always desired by an employer.
Mediocrity is honestly what many customers need. They don't need developers of Herculean strength that can create software of unfathomable complexity, they need a patch to their billing system (or something similarly trivial).
I dont think medicine or law are good examples for that. Medicine has you sleep deprived for years as a matter of policy because you are expected to work so much and law tend to be quite similar. At least in USA. I mean, yeah, you are expected to learn on the job, but the job is 100 hours a week.
Contrary to that, all older developers I know learn on the job and developed strategies how to make it possible to learn on the job.
> Some people should not be in this industry -- not because they don't have the chops; but because they don't actually want to put in the time and effort to develop their skills. And it is an overwhelming task.
In what world is it an overwhelming task? Maybe I've landed only at amazing companies but nobody is working the full 8 hour workday. There is time to relax and read random slightly interesting technical things as a break. There are pushes to use slightly interesting technical things in your projects (regardless of how useful it is -- because we need to keep our resumes updated!) and most of the time management will allow it.
The hyperbole from software engineers on how hard this piss easy "profession" is, is just FUD and only serves to keep away people with low confidence issues. In other words, what you are doing is not only keeping potential candidates away, but greatly keeping underprivileged candidates away, and it'd be great if you stopped.
Software engineering given it's current state as the wild west is not a difficult profession in the slightest. It's not law, it's not finance, it's not medicine. We work (relatively) short hours for great benefits and have the ability to work from wherever we want on certain days. Your grades don't matter and you don't need to spend days learning anything other than what's tested in an interview setting or used in production.
Passion is overrated and stupid and it mostly comes from privileged people who had the time to fuck around on the computer all day (and execs wanting to exploit the workforce a bit more) -- not realizing that many people can do what they do given time and mentorship.
There are few other jobs that give you more bang for your buck in terms of effort if you're okay with ~200k/yr being your cap.
You might have had good luck with other engineers, I have definitely encountered people who could not seem to get their head around even basic programming concepts. It comes easy to some given the appropriate time/effort, but I have definitely encountered people who did not seem able to pick it up.
It is also a difficult field given that it is one of the few where you probably will have to drop a huge, comfortable skill set every 2-4 years and start over again with a new codebase, different frameworks, and different languages. That does not happen in finance, medicine and law. If it seems easy to you, try jumping into a well established but poorly written project, built using libraries/frameworks you are not super familiar with ;).
I definitely agree with the hours thing though, if you establish yourself at a company you can pull off some pretty amazing work/life balance things.
You are not starting over every 2-4 years. A lot of what you learned is reusable, those frameworks resemble each other great deal. Even with changing languages, it is hard only when you are changing paradigm (procedural to object to functional). Things like syntax take less effort to pick up and re-learn. Algorithms, debugging and structuring of code and similar meta skills remain. Moreover, you dont have to chase every fad. They come and go and it is perfectly ok to skip some of them. Focus on things that you need or that promise longevity. Nobody cares now that I skipped COM+ years ago, nobody cares that I skipped browser differences or ruby just a few years ago and nobody will care that I am ignoring angular and python now.
I did jumped into established projects using libraries/frameworks I was not at all familiar with and liked it. Thankfully companies here are willing to hire like that. It is period when they literally pay you for learning on the job. That is awesome, it is hard to ask for more.
I think it's an issue with teaching. I am teaching a few people in my spare time and the way highschool (& sometimes university) teaches programming is not conducive to learning or understanding. I've still yet to meet a kid who wants to learn that can't learn it given reasonable time and proper explanation. Given the Internet likes explaining basic concepts in forty different ways, I think as time goes on learning CS only becomes easier.
With good fundamentals I think picking up new frameworks and different languages is fairly easy. With the exception of Rust and Haskell, which I'm interested in but never got around to using well, the other languages all seem to come fairly easy after a month or two. There will always be idioms you do not know or fail to remember but that's why there are linters, code reviews, and senior engineers.
It's definitely daunting to jump into poorly written products, and I feel every company has at least a section of their code base that is like this, but that's what good on-boarding and ramping up is for. These are all process issues and not fundamental issues with computer science.
Very few companies I've been at are good at one of these things let alone all of these things. A lot of the time you _are_ slogging at it alone and sometimes you go alone for too long because of ego or lack of confidence. These are all organizational and process issues. Some of it is individual issues too that one must overcome, but making it seem like only the passionate succeed in software engineering like everyone is the top 0.01% of their craft is harmful to the profession as a whole.
My solution to most of these problems is to find a mentor at your company. Anyone who knows what they're doing. I find most people are super nice when you ask questions as long as you are willing to learn and aren't just trying to get them to do something that seems annoying (i.e. asking ops people why your build fails...). I've never met an engineer who _doesn't_ want to talk about how something is designed, the pitfalls, and the hacky work arounds. People like being useful to other people. Let them be useful.
Caveat: I've met a few "legacy" engineers who were hired early and have a negative influence on the direction of the architecture. In companies like these? You can just leave. Everyone wants a good software engineer and as long as you're willing to relocate, you'll land somewhere fine.
Your post boils down to "fake it until you make it" because while you criticize the average programmer, you don't realize that the programming industry has significant influence on how it shapes the narratives about programming skill and how people in the industry perceive things that they "need to know".
You guys (people claiming to be the top global 1%) constantly shift practices, frameworks, and career directions and the only reason you've been so successful at it is because you have a loud voice, and haven't actually put any work into having a cohesive voice about how to train and develop programmer careers. That's why you don't have a golden path for early programming careers -- there is no state of the art to practice at because the field is just chaos with its own direction. It's like rolling the dice to find out which level of Math you'll be taking this year. It could be pre-algebra, or it could be calc III. You don't know because the dice roll represents some fashionable trend in the industry.
If you could actually do this work and answer this question, you'd have a class of useful programmers whom you know will be able to work at a particular level in exchange for a fair wage.
If someone wanted to join this class, then it should be very easy for them to figure out what skills they need and what tests they should take to figure out on their own whether they belong. You can then assess them using similar tests.
In a world of "fake it until you make it", yes, you over-inflate your confidence and appearance of skill. You go until someone completely rejects you because why not? There's no legal repercussions since it's up to the business to do its due diligence. If a business is not happy with its hires, it indicates that they still don't have a good hiring process which gives them the signals you need.
>But here's the catch. "Everybody" is not looking for the average programmer. They are looking for the top 1% of applicants.
IME that's market dependent. One of the reasons I left Singapore was because it was abundantly clear that almost all employers had neither the ability to accurately assess programming talent nor the inclination. They all wanted average drones, cheaper the better.
Moreover, actual competence is routinely confused with the ability to recite algorithms you'll never need to implement, encyclopedic knowledge of obscure APIs or a stint working at a high profile employer.
So yea, in theory most companies want the top 1% of programmers but I'm sure that most wouldn't even recognize them if they saw them.
If you need everybody to be top 1%, then you have management problem. Whether it is that majority of people get demotivated fast and stop caring or whether it is that there are no modules or tasks that are simpler, it still boils down to management problem.
If you have well defined APIs and modules, then you can actually give one low risk to cheaper junior. If he or she manage to do it great, awesome. If it is too much mess, then senior will redo it when change requests come first time. Most of the time, the module is not perfect, but is useable, junior learned and was useful. That is just one example of how to manage less then super genius super experienced programmers.
It is not so difficult to write good code and some tasks are easier then others. Writing good code boils down to being predictable plus following some rules. Comes easily with experience. But funny thing is, puzzles, whiteboards and tricks do jour have little to do with writing good readable code. They select for people who are good in solving short competition like problems. That is not nearly the same as writing large readable maintenable system. It is useful, in some projects more then in others, but it is still different skill.
That gets us to assigning tasks to people based on their personalities and skills. Someone who is super great in algorithms may write ugly code, someone who writes nice code can have hungups on frustrating tasks and someone learns fast but gets bored easily. Instead of complaining about those three being imperfect, good management assigns them different tasks (or have them choose tasks).
> Insecure or maybe well known as imposter syndrome hits me hard many times from when I started as an iOS developer
Used to feel the same when the Python-crowd harassed me on choosing PHP over Python for webdev. I got my revenge when the python-devs i knew started rewriting their entire projects in ExpressJS/NodeJS due to scaling-related issues and mine still outperform them after 5 years of service.
I listened to this podcast where they were trying to figure out why some car salesmen sell 2x or 3x the cars of the next best guy on the lot. They found a pattern where the best performers would maybe briefly celebrate a sale and then immediately think "Oh god, I'll never sell another car, gotta get cracking right away." The less successful guys would go back to their buddies and brag, tell stories and go home early.
Insecurity itself isn't necessarily a predictor of failure, it depends on what you turn it into.
That being said, I'd much rather be the less successful guy than the guy constantly afraid of failure. "Productivity" is only as good as it advances your own personal life goals, and I don't think it should come at the expense of mental wellness.
This is also a form of self selection. If you believe that working hard is not worth what you get from it, you won't do it and someone else will.
The less successful guy would also "rather" be himself than the other guy, because he too believes the other guy must be trading his mental health for his productivity.
The successful guy doesn't see it that way. He's happy when he sells a car, and he's happier when he sells more cars. He spends his whole day doing his job, maybe even does research at home. He still enjoys his time with his family, has whatever hobbies he invests his free time in (presumably also more successfully than the other guy). He gets to retire earlier, and he knows it, and that gives him more motivation to be successful.
It is absolutely tragic that people can have the idea that less success is more happy. Some people feel better working harder and you shouldn't have to attribute some opaque negative consequence to them to feel better about the gap.
This is super interesting (car sales). I know you have probably a lot of better things to do than answering strangers' questions, but, if you could, would you mind spending 60 seconds trying to find the post and post it here?
58 comments
[ 2.4 ms ] story [ 90.7 ms ] threadIt means you're a white man and apparently it has become an accepted form of discrimination.
Pretty dumb at the end if you ask me.
Tools change like fashion. What is "hot" today will be nearly frowned on in 5 years and forgotten in a decade or so. In 20 years the fundamentals still matter, the tools, not so much (Pascal? Powerbuilder? Win32 in C?)
A smart developer can learn any tool. Hire for aptitude, not today's toolset.
Interviews can help accommodate this by allowing the candidate to solve a coding test in a language of their choice, while also inquiring about the candidate's learning plans. (Want to make sure they are willing to adapt to the team's tools and not try to force the team to adapt to them!)
I took a job once where the code base was in a FORTRAN-derivative language. I had never used FORTRAN or anything like it. Not a problem. I studied the code. I studied the docs. I figured it out and did the work. I would expect nothing less of any other competent developer.
Another job had a toolchain based on NodeJS on the server-side. Never used NodeJS. Not a problem. Studied the code. Studied the docs. You know the story.
The key skill is a developer's willingness and ability to learn the tools that are desired for the job at hand, and to accept and learn new tools when the time is right.
"Hi, we are not going to pay you, or not very much, but please be at the same level as senior that are already working for us"
I had interns back in the day I had an office (and not working from home) and I always made them work on basic tasks under my supervision. Once I had one woman who was very good, and she worked on a website that ended in production, but most of the time the purpose was to work on internal projects that can be used even if not perfectly polished. You know, stuff you always say you're going to do some day, but you don't.
The advantages were on both sides. They learned real life cases, under my supervision, and I had the tools I didn't.
Disclaimer : I'm French so maybe my example is not relevant.
Code challenges at least have the capability of being very useful. We try and present the type of problems people will have to be solving in that position; if they struggle with it and someone else excels, they have done their job.
Cool, we can finally remove CompSci degrees from job postings.
1) Because desirable internships have more candidate applications than available slots. E.g. Google has 40,000 students wanting an internship but only 1500 slots.[1] With that supply & demand ratio, Google can be selective via difficult coding tests.
2) Even though internships are unpaid, companies evaluate interns to potentially offer permanent employment. If so, a company like Google would want to fill those 1500 slots with "the best" rather than randomly pull from 40000 candidates.
That's how it is at the hot tech companies. Maybe other internship programs outside of tech sectors such as Peace Corps think of interns differently.
[1] https://www.fastcompany.com/1683136/how-to-actually-land-an-...
Having said that, our industry is full of a lot of people who probably are not well suited for the job. Quite a few people look at the 6 figure salaries that you can get in some places in the US and figure it's a cushy way to get rich. Similarly, there are tons of jobs. Everybody is looking.
But here's the catch. "Everybody" is not looking for the average programmer. They are looking for the top 1% of applicants. Anybody who is hiring (i.e. everybody) can verify this. How man CVs do you get a month? How many do you interview? How many do you hire? And even then more than half the time I reckon companies are dissatisfied with the programmers they hire.
So there is actually a huge supply of average programmers that nobody wants. The average programmers aim at the "barely works" bar, and having hurdled it think they are senior programmers. A year or two under their belts, they demand their incredible wages.
At the same time, we all ask ourselves, "How can we protect ourselves from the hordes of untalented hacks knocking at our door?" Whiteboards, puzzles, trick-du-jour. It doesn't matter, because the real problem is what I stated at the top.
Confidence is important because writing good code is very, very difficult. Writing terrible code that barely works is not so difficult. We think we need to protect ourselves, but we don't need binary barriers to protect us from the untalented hacks. We need a better attitude. We need to realise that programming is a skill that takes time and effort to develop.
Some people should not be in this industry -- not because they don't have the chops; but because they don't actually want to put in the time and effort to develop their skills. And it is an overwhelming task. There is so much to learn that you will be drowning in it for years (another reason people put their fingers in the ears and think they are amazing).
So to any "young" programmers (of any age), my advice to you: Have courage. Have confidence. Love what you do because it's a crappy, horrible job if you don't -- no matter how much you get paid. And for those who don't love it... there are lots of jobs that are not programming, but are still in the industry. Quite a lot of them even pay more than programming! Seek them out.
And I think this is the wrong question to have.
"How can we get this new hire up to our standards?" would be better. Problem: once they're up to speed they'll be poached by a competitor. Answer: have real salary upgrades every-time some senior think they're better (not once a year at some review shitshow). Have a good working environment so when one of your people get to a competitor they only have good things to say about you. Then they may come back if things are not as good and may turn some of their new colleagues to send you their resumes.
That's expensive. But that's investing in your workforce. And this should be used not only for your coders but everyone.
Out of curiosity, what roles do you think pay more than programming? Product? PM?
Edit: Forgot about sales! I have a neighbor who works from home in sweat pants but makes insane money in tech sales. Though, he has admitted that the easy stuff is drying up.
During that time, I haven't met a single soul who would be able to describe what a call stack is and how it works, in rough terms. I don't have a CS degree, but I would imagine that it is something you would learn in the first year - I was tought it in high school (but have actually learned it much later, of course). Best that I got was a description of stack data structure and mumblings about how "variables go there and it's faster than heap". And the amount of bullshit that people came up with, looking completely confident, instead of honestly saying "I don't know it", is mind-boggling.
I remember an old Delphi interview where they asked me what a I already forgot was. I didn't know by name, but once they showed me what they were talking about, I could explain it in depth. They ended up hiring me and I fixed their broken DSS engine and it ended up in a lucrative M&A.
Anyway, standard IQ tests have sections for various skills. Among the ones that are important for programming is abstract thinking and pattern recognition. You should be testing for that rather that word/definition association.
http://www.thinktonight.com/WISC_IV_subtests_s/331.htm
The fact that you include "return addresses" already shows that you understand the concept much better than developers I interviewed.
It's not about knowing the trivia that you can google - it's about knowing that you should google something when you need it.
This isn't true. The worst developers I know are also the most confident. They think their code is perfect the first time and they don't need to learn any more because they believe they already know everything there is to know. The more confident they are the worse their quality of work is. Luckily they are few and far between.
I'm not saying nobody should have any confidence only that having too much is very detrimental.
> Anybody who is hiring (i.e. everybody)
We aren't hiring.
> more than half the time I reckon companies are dissatisfied with the programmers they hire
Your organization has a problem. We've hired "duds" only a few times. The vast majority of the programmers we have hired have been just fine. Or maybe your expectations are just entirely unrealistic?
>So there is actually a huge supply of average programmers that nobody wants. The average programmers aim at the "barely works" bar, and having hurdled it think they are senior programmers. A year or two under their belts, they demand their incredible wages.
That has not been my experience.
> Love what you do because it's a crappy, horrible job if you don't
You don't have to love it, just not hate it.
(My point was confidence leads to worse code, not better. In fact, "confidence that you can achieve something better" is actually really a lack of confidence.)
This is something that is near and dear to my heart, so I'm gonna take the opportunity to rant on it a bit. There are quite a few high-paying and fast-moving fields.
Pretty much everything under medicine or law moves is moving on a week-to-week and even day-to-day basis, just like software development. Unlike software development, practitioners in these fields get paid to stay up to date, as part of their day jobs. Lawyers spend a good chunk of their days just reading the latest case reports that are relevant to their field, and boy howdy do our legal systems churn out a lot of reading for them to do.
It's pretty much only in software development that we expect professionals to stay up to date and develop new skills /in their spare time/. There would be a lot more 1% developers out there (or rather, we'd be able to look for the 5% or 10% rather than the 1%) if companies were willing to have their teams spend 4 hours a week training, but no one is willing to do that.
I have guesses on the causes of this industry-wide unwillingness to train, but one thing is for sure: this situation will never resolve itself as long as we honestly and unironically expect members of the field to spend their evenings and weekends learning new algorithms and languages instead of playing with their kids or chilling with their mates.
You know why so many developers settle for mediocrity? Because mediocrity pays the rent, and no one is supporting their path to excellence.
I guess I say all that to say is that people trust lawyers and doctors to be professionals. If they say that they need something, such as time to self-improve -- or the right tools, people listen. The respect their profession bestows upon them gives them an amount of personal clout that most of us don't get by virtue of simply being a dev.
My current theory is it's at least somewhat a result of unions losing power. A union's strategy is to have as many people employed for as long as possible, so it's inherently a long term strategy. The better the company does long term, the better the union members are. I would say unions are the champions of long term strategy for self preservation. If the company goes out of business, all the union members are out of jobs.
Executives are more short term thinkers today. They want quarterly results and they have incentives based on those results (both quarterly and annual) and almost no long term results outside of accumulation of short term incentives. Executives also have the notorious golden parachutes which further shields them from the personal costs of short term thinking. This of course rewards short term thinking rather than long term thinking.
Training is a long term investment, not a short term investment. Short term thinkers want to find someone who will 'hit the ground running,' as I've sure you've heard. Ideally that's what anyone would want. The trouble is, that rarely happens once, much less for an entire team. Short term thinkers can't think outside of that strategy and therefore, we are where we are.
Some reasons I can think are people: - don't want any more meetings; - are bad at having a merit driven discussion
Every verdict is effectively the new rules that lawyers will play by the second that it is made; you could lose the case for not knowing a specific verdict. Medical professionals practice an ancient field that has no interest in gung-ho, extraneous solutions to problems that have already been solved. Software development is one of the few fields where people working it think that learning some oddball, corner-case framework that got its start because the original developer didn't like the code style of some other oddball, corner-case framework is necessarily and always desired by an employer.
Mediocrity is honestly what many customers need. They don't need developers of Herculean strength that can create software of unfathomable complexity, they need a patch to their billing system (or something similarly trivial).
Contrary to that, all older developers I know learn on the job and developed strategies how to make it possible to learn on the job.
In what world is it an overwhelming task? Maybe I've landed only at amazing companies but nobody is working the full 8 hour workday. There is time to relax and read random slightly interesting technical things as a break. There are pushes to use slightly interesting technical things in your projects (regardless of how useful it is -- because we need to keep our resumes updated!) and most of the time management will allow it.
The hyperbole from software engineers on how hard this piss easy "profession" is, is just FUD and only serves to keep away people with low confidence issues. In other words, what you are doing is not only keeping potential candidates away, but greatly keeping underprivileged candidates away, and it'd be great if you stopped.
Software engineering given it's current state as the wild west is not a difficult profession in the slightest. It's not law, it's not finance, it's not medicine. We work (relatively) short hours for great benefits and have the ability to work from wherever we want on certain days. Your grades don't matter and you don't need to spend days learning anything other than what's tested in an interview setting or used in production.
Passion is overrated and stupid and it mostly comes from privileged people who had the time to fuck around on the computer all day (and execs wanting to exploit the workforce a bit more) -- not realizing that many people can do what they do given time and mentorship.
There are few other jobs that give you more bang for your buck in terms of effort if you're okay with ~200k/yr being your cap.
It is also a difficult field given that it is one of the few where you probably will have to drop a huge, comfortable skill set every 2-4 years and start over again with a new codebase, different frameworks, and different languages. That does not happen in finance, medicine and law. If it seems easy to you, try jumping into a well established but poorly written project, built using libraries/frameworks you are not super familiar with ;).
I definitely agree with the hours thing though, if you establish yourself at a company you can pull off some pretty amazing work/life balance things.
I did jumped into established projects using libraries/frameworks I was not at all familiar with and liked it. Thankfully companies here are willing to hire like that. It is period when they literally pay you for learning on the job. That is awesome, it is hard to ask for more.
With good fundamentals I think picking up new frameworks and different languages is fairly easy. With the exception of Rust and Haskell, which I'm interested in but never got around to using well, the other languages all seem to come fairly easy after a month or two. There will always be idioms you do not know or fail to remember but that's why there are linters, code reviews, and senior engineers.
It's definitely daunting to jump into poorly written products, and I feel every company has at least a section of their code base that is like this, but that's what good on-boarding and ramping up is for. These are all process issues and not fundamental issues with computer science.
Very few companies I've been at are good at one of these things let alone all of these things. A lot of the time you _are_ slogging at it alone and sometimes you go alone for too long because of ego or lack of confidence. These are all organizational and process issues. Some of it is individual issues too that one must overcome, but making it seem like only the passionate succeed in software engineering like everyone is the top 0.01% of their craft is harmful to the profession as a whole.
My solution to most of these problems is to find a mentor at your company. Anyone who knows what they're doing. I find most people are super nice when you ask questions as long as you are willing to learn and aren't just trying to get them to do something that seems annoying (i.e. asking ops people why your build fails...). I've never met an engineer who _doesn't_ want to talk about how something is designed, the pitfalls, and the hacky work arounds. People like being useful to other people. Let them be useful.
Caveat: I've met a few "legacy" engineers who were hired early and have a negative influence on the direction of the architecture. In companies like these? You can just leave. Everyone wants a good software engineer and as long as you're willing to relocate, you'll land somewhere fine.
You guys (people claiming to be the top global 1%) constantly shift practices, frameworks, and career directions and the only reason you've been so successful at it is because you have a loud voice, and haven't actually put any work into having a cohesive voice about how to train and develop programmer careers. That's why you don't have a golden path for early programming careers -- there is no state of the art to practice at because the field is just chaos with its own direction. It's like rolling the dice to find out which level of Math you'll be taking this year. It could be pre-algebra, or it could be calc III. You don't know because the dice roll represents some fashionable trend in the industry.
If you could actually do this work and answer this question, you'd have a class of useful programmers whom you know will be able to work at a particular level in exchange for a fair wage.
If someone wanted to join this class, then it should be very easy for them to figure out what skills they need and what tests they should take to figure out on their own whether they belong. You can then assess them using similar tests.
In a world of "fake it until you make it", yes, you over-inflate your confidence and appearance of skill. You go until someone completely rejects you because why not? There's no legal repercussions since it's up to the business to do its due diligence. If a business is not happy with its hires, it indicates that they still don't have a good hiring process which gives them the signals you need.
IME that's market dependent. One of the reasons I left Singapore was because it was abundantly clear that almost all employers had neither the ability to accurately assess programming talent nor the inclination. They all wanted average drones, cheaper the better.
Moreover, actual competence is routinely confused with the ability to recite algorithms you'll never need to implement, encyclopedic knowledge of obscure APIs or a stint working at a high profile employer.
So yea, in theory most companies want the top 1% of programmers but I'm sure that most wouldn't even recognize them if they saw them.
If you have well defined APIs and modules, then you can actually give one low risk to cheaper junior. If he or she manage to do it great, awesome. If it is too much mess, then senior will redo it when change requests come first time. Most of the time, the module is not perfect, but is useable, junior learned and was useful. That is just one example of how to manage less then super genius super experienced programmers.
It is not so difficult to write good code and some tasks are easier then others. Writing good code boils down to being predictable plus following some rules. Comes easily with experience. But funny thing is, puzzles, whiteboards and tricks do jour have little to do with writing good readable code. They select for people who are good in solving short competition like problems. That is not nearly the same as writing large readable maintenable system. It is useful, in some projects more then in others, but it is still different skill.
That gets us to assigning tasks to people based on their personalities and skills. Someone who is super great in algorithms may write ugly code, someone who writes nice code can have hungups on frustrating tasks and someone learns fast but gets bored easily. Instead of complaining about those three being imperfect, good management assigns them different tasks (or have them choose tasks).
Used to feel the same when the Python-crowd harassed me on choosing PHP over Python for webdev. I got my revenge when the python-devs i knew started rewriting their entire projects in ExpressJS/NodeJS due to scaling-related issues and mine still outperform them after 5 years of service.
Insecurity itself isn't necessarily a predictor of failure, it depends on what you turn it into.
The less successful guy would also "rather" be himself than the other guy, because he too believes the other guy must be trading his mental health for his productivity.
The successful guy doesn't see it that way. He's happy when he sells a car, and he's happier when he sells more cars. He spends his whole day doing his job, maybe even does research at home. He still enjoys his time with his family, has whatever hobbies he invests his free time in (presumably also more successfully than the other guy). He gets to retire earlier, and he knows it, and that gives him more motivation to be successful.
It is absolutely tragic that people can have the idea that less success is more happy. Some people feel better working harder and you shouldn't have to attribute some opaque negative consequence to them to feel better about the gap.