As someone who interviewed dozens of bootcampers I can give some insight.
1) Most of the bootcamps teach the basic of front-end, and a lot of them, teach by doing without explaining a lot of basic concepts. They are basically money grabbers and throw these people out of the door as fast as possible to get their money back.
2) A lot of the students are in for the money, not for the love of the job. Sorry, but it's true. I don't mean to include everyone, but out of 30 students, only 2 kept working in my previous company, they weren't good developers, but they loved the job and kept learning and improving themselves. Nothing wrong with pursuing a good paycheck, but in developers world in order to keep being relevant in the next 2/3 years you need to keep sharping your skills.
3) The best developers I worked with are the self-taught guys/girls who learn on their own before they even hit the college.
The most boring developers I work with, the the ones who only learn to code while in college and never developed any interested to learn before that.
But the most horrible devs I work with came from boot camps. Not their fault, it's just how bad these bootcamps are.
I went to a smallish private university and in the first year, there were about 50 people who intended to go for a CS degree. By year 2, there were about a dozen left. Every single one that said 'I heard there were good jobs in it' was gone. CS and writing code is not like many different arenas in that if the homework takes you 8 hours to understand, then it takes you 8 hours to understand. If you don't understand it, it is an order of magnitude more difficult to 'wing it' or get 'partial credit' when there is absolute proof of your lack of understanding with non-compiling or non-functional code.
I studied CS and Philosophy. I could phone in a philosophy paper if I wanted. I could not phone in a linked list implementation. I know companies loathe the idea like no other, but software engineering is a skill that is difficult for most people to acquire and is likely to remain that way. Mostly it boils down to peoples understanding and value they place on logic. Anyone with a good grasp on, or even just a high value for logic, can learn to code. No one who sees logic as 'nitpicking' can learn to build systems that function predictably, reliably, and accomplish a defined goal.
Math has the concept of non-compiling code: a proof that is wrong. You get partial credit if you get early steps right, and more if latter steps are right.
The idea that code that doesn't compile is not worth partial credit is wrong in academics. In the real world the code needs to compile first, of course, then run. However if your professors cannot look at your code that doesn't compiler and decide how much partial it is worth there is a problem.
That said, getting code to compile is a trivial part of the problem.
> In the real world the code needs to compile first, of course, then run
This is not true in my experience as a professional. I write pseudocode all the time. Often the fastest way to evaluate architecture choices is to sketch out your architecture, sketch the consumers of your proposed API, and see what issues come up.
Making this kind of code compile is a waste of time. Reading code without the computer is a crucial skill.
Graders require compiling code because it's easier to grade.
The same way as you would in every other type of education. If you know what you are doing, it is easy to see how close the student came to getting it right or if they were completely on the wrong track.
I passed a lot of my math and physics courses even though the majority of my proofs were incorrect in some way. I didn't get full credit, but I got enough to get some.
I think it's also why I have friends that did Philosophy before going to Law School. Despite what was said above, good philosophy papers do take some rigor of thought.
Same here. Philosophy and coding much later.
All through my twenties Aristotle to Sartre, read
every page twice and reduce to comprehensibility in
context.
I think it depends on the individual and the class. With several philosophy classes I saw scores on weekly papers go from around 9/10 to around 5/10 if I tried to wing it and do it at the last minute.
similar story here. small private college, there were maybe 25 people tops in intro to Java (2nd class you would take) I TA'd a few times; and that's mainly because it fulfilled a lab science credit somehow. I graduated with 8 other CS majors. I had a few classes that were 1:1 with the professor.
> A lot of the students are in for the money, not for the love of the job.
Who cares? Can they do the job or not? Do they have the work ethic and professionalism to continue to do so?
The vast majority of people, including those who excel at their respective fields, don't love their jobs. This industry needs to stop using "passion" as a lazy signal for work ethic.
> The most boring developers I work with, the the ones who only learn to code while in college and never developed any interested to learn before that.
2. In for the money, but also love the job, codes on spare time
3. Category 2, but no more free time (family, older parents)
I was in Category 2 but now on category 3. I show up to work early, work intensely, do not waste any time, and try to leave at a normal hour. On weekends, instead of open source projects, I'm spending the time with my mom who is getting much older and requires help and emotional support from the family. That does not mean I have poor ethic or lack of interest, it just means I have a lot of family commitments. I am very productive at work, I love it, but there are clear boundaries unless there is some major deadline or production issue. Speaking of Production issues, I write very very good code to ensure I dont have Prod issues and/or I can quickly do a root-cause-analysis of issues that pop up. My personal needs focus me like a laser on productive time at the office.
Embrace the time you have left with your mother. Work will always be there, and there is no job more important than your family. Do not give on your boundaries.
I spent the last 2.5 years of my mother's life (she passed away suddenly last month at the age of 59 from a brain hemorrhage) working for a startup, not making more time to spend with her because I thought I'd have at least another 5-10 years with her, and my heart hurts every day thinking about how I didn't spend more time with her. Do not make my mistake. It's just code, you're not saving the world.
Sorry to hear that!!! I was a little kid when my grandfather died and for some reason I felt guilty and thought I had abandoned him in his last days. It was such a bad feeling and it still revisits me from time to time.
Interest usually correlates with the desire to learn and explore on one's own time. If you have a team of interested developers/hackers, then the lack of enthusiasm can drag the team down, both in knowledge and culturally.
This isn't always true, of course. Some developers can have excellent skill and have no interest in programming outside of work. I have a coworker that does virtually nothing outside of work, doesn't keep up with current events outside of what our group discusses, but she is a great programmer and picks up on things very quickly. She shows genuine interest in the work she does at work. She's been with us for nearly nine years. Culturally, she's different than me and another one of our co-workers in a more fundamental sense, but as part of our _team_, she is a perfect fit.
> Interest usually correlates with the desire to learn and explore on one's own time.
I don't agree. Interest in doing a good job (i.e. work ethic) usually correlates with this, but I do not think work ethic corresponds very well with interest in the field.
> If you have a team of interested developers/hackers, then the lack of enthusiasm can drag the team down, both in knowledge and culturally.
I think part of my problem with the statements in this thread is that I would never put together a team of hackers to run a business. Your statement implies a team that is interested in tehcnology for technology's sake rather than as a tool to solve a business problem.
The world isn't that binary. No one is suggesting you hire a bunch of people who don't care at all about solving actual problems and who would just screw around all day messing with whatever shiny object caught their eye.
The discussion is whether someone who is just in it "for the paycheck" will be able to solve those business problems as effectively as someone who has a deeper interest in technology for technology's sake. By itself, that's obviously not enough signal to say one way or the other. There certainly are extremely valuable people who don't code outside of work, follow new language and tool discussions online, etc. I think it's equally obvious though that such an interest is a positive signal. If you told me nothing else about two potential hires except person A writes Java at work and has no interest in the field beyond that, and person B writes Java at work, but has a Github page full of utilities she wrote in Go, Lisp, Haskell, whatever, I'd bet a small amount that person B is probably better at solving technical problems. You can't say that for sure, and any of the myriad other factors that actually do matter could break the other way and make person A the better hire for an actual business, but outside interest is a positively correlated trait.
> I don't agree. Interest in doing a good job (i.e. work ethic) usually correlates with this
I wasn't expressing a 1:1 relationship. I also expressed an example where this wasn't the case: interest in the position and the work we do, but not a personal interest outside of work.
> Your statement implies a team that is interested in tehcnology for technology's sake rather than as a tool to solve a business problem.
I just happen to be a hacker that was hired by a business. That wasn't why I was hired---I was hired because of certain qualities that so happen to be a consequence of my being a hacker, and because of fundamental interest in certain topics (which also included side projects).
I'm certainly not interested in technology for technology's sake: I'm the author of a large system on which one of the core parts of my company (the company I work for, not a company I own) is based (raters for an insurance agency), and it was made using practical, business-conscious decisions. My coworker (he doesn't identify as a hacker) is Technical Director.
Many programmers who enjoy programming will have a preference for hiring other programmers who also enjoy it. That doesn't mean they can't hire dispassionate programmers but that still doesn't erase the preference for passionate programmers.
>This industry needs to stop using "passion" as a lazy signal for work ethic.
There's definitely a place for dispassionate programmers (as that's probably the majority of programmers who just think of it as a "job"). However, it's wrong to vilify programmers-that-love-their-craft having a preference for other programmers-that-love-their-craft.
This isn't about preferences. This is about the false dichotomy proffered in the original post I responded to, and elsewhere from time to time, that there exist only programmers-who-love-their-craft and programmers-who-just-want-a-fat-paycheck, and that the former is orders of magnitude better than the latter. I also think "love" is significantly stronger than "enjoy" or "interested in".
> Many programmers who enjoy programming will have a preference for hiring other programmers who also enjoy it. That doesn't mean they can't hire dispassionate programmers but that still doesn't erase the preference for passionate programmers.
Exactly, and it isn't just 'Work Ethic', I wanna work with these guys [1] in 'Silicon Valley' tv show who would go around doing a Jerk off calculation just because it is a fun calculation to do. Not just people with strong 'Work ethic'.
How is anything you quoted "vilification"? I look at it the same as I look at, say, the interview process: he or she is pointing out a flaw in the reasoning used to support "passion as a proxy for merit," which is basically what that preference is.
Probably because you want to grow as a professional and it's much easier in an environment where our coworkers also want to grow.
If they're content with where they are, there are numerous problems:
• as the business case becomes more complex, they won't adapt
• as you grow and progress, you'll be promoted and they won't. No one wants to work in an atmosphere of resentment.
• you want to learn from your coworkers while they learn from you. If it's one way, you're just slowing yourself down.
I don't want to work at a place filled with guys who want to do the same job for the next ten years. That workplace is going to be commoditised. They'll eventually find themselves on the Internet complaining about H1-Bs and outsourcing and how git is hard to use and technical interviews are evil because they have ten years of experience.
No thanks. This field is privileged in that there are lots of us who like our job a lot. Life's too short to settle for boring coworkers.
Growing as a professional requires some combination of drive, ambition, and work ethic. Interest in the job may make those things easier to find, but it is not a primary driver.
> Growing as a professional requires some combination of drive, ambition, and work ethic.
People usually call those types of qualities "passion," "love of job," or "interest."
You keep trying to work around definitions to suit your narrative when people are just trying to have an honest conversation. You are shoving intent into the OPs post that isn't there. Simply put, what they are saying is that those from bootcamps are there doing the what they think is the bare minimum in order to keep getting a paycheck at that moment.
You might think, "Hey, just raise the minimum and they'll raise with it, it's your fault for having low expectations!" However, when those expectations are raised, you rail against them. You can't have it both ways.
You can't argue for someone lacking drive, ambition, and work ethic, and at the same time bemoan people for demanding that.
Passion has become a synonym for being in love with a career. As you said: "love of job".
Mixing a complex sentiment like love with coding is frankly ridiculous and I would argue undesirable.
Instead we should precise terms like drive, interest in technology, motivation to learn, etc. These make sense and don't bring any emotional baggage with them.
You're the only one so far who's mentioned the reason this is important to me.
I want to learn from my coworkers. Making decisions that require evaluating new software or new techniques is difficult and risky, having more than one damn person who can contribute to that process makes a huge difference. Plus, I just like learning things from people.
Sure, it's very good for the business if they keep up with new developments in a rapidly changing field, but personally it's most important to me that my coworkers and I are helping each other sharpen our skills and make tech decisions responsibly (being fad driven is worse than being out of touch, I don't mean just knowing about what's "hot right now").
I care. For 4 years, I went to lunch with a team of "just a job" devs who only wanted to talk about celebrities, and gave me blank stares and laughed about how they "forgot all that theory stuff from college". It sucked.
This also comes back to broader discussions about programmers needing to have worked on this stuff since they were kids. Perhaps uniquely among STEM subjects. No one expects a chemical engineer to have done anything other than to have enjoyed and done well in high school chemistry prior to college or to have chemical engineering "side projects."
>Perhaps uniquely among STEM subjects. No one expects a chemical engineer to have done anything
Computer programming as a self-motivated hobby is not unique in this. Many electrical engineers started playing with electronics as kids (e.g. disassembling radios, wiring up homemade amps, etc). Many mathematicians "play" with math as kids before they go to college and get a teaching/research position. (E.g. Andrew Wiles was 10 when he was captivated by Fermat's Last Theorem.) Many biologists and zoologists when they were kids had a keen interest in nature and animals (beyond the typical children's "dinosaurs are cool" stage). Same for astronomy.
Many != all. I'm a senior engineer now only a few years removed from school but I'd never touched programming until my 2nd year in college (switched majors 3 times). I'm obviously interested in tech or I wouldn't be here but I'm certainly not spending my free time trying out new technologies or coding for fun, and honestly I never have. I care about my job, about my craft, about moving up but I get plenty of practice in the 8+ hours i spend every day at work. Outside of work I have a life that doesn't involve machines, and this idea that in order to be good at your job you need to have a burning passion for coding is unhealthy for the field. Not to mention that half of what makes a good engineer is stuff completely unrelated to how well you program.
No one expects a chemical engineering 1st year student to have mastered organic chemistry already. Just as no one expects a 1st year mechanical engineering student to thoroughly understand rigid body dynamics at age 10.
Yea maybe they built an RC plane or did some home experiments, but if anyone is doing these things at a young age they are clearly far above their peers.
> Andrew Wiles
Example here-this man is extremely intelligent, it's like using Einstein as an example that anyone can be a genius physicist that changes the world. No, they can't.
We need to just call it what it is: arrogance and gating. "If you didn't do what I did, you must certainly not be any good." Which is an absolute shame
Quite a few comments on this thread should be required reading for anyone seeking to understand some of the cultural "shortcomings" of the software industry generally and the software industry in Silicon Valley specifically. This idea that not having had an all-consuming for programming since childhood and not maintaining an active Github account for all your side projects means that we don't want your kind is toxic.
>This idea that not having had an all-consuming for programming since childhood and not maintaining an active Github account for all your side projects means that we don't want your kind is toxic.
Then you are not aware of the toxic comments from your peers who agree with you.
To recap...
Group 1: programming-is-just-a-job -- the majority -- The programmers who want to compartmentalize their programming strictly to 40-hours work week so they can have a life outside of computers. Programming is just a means to an end. Programming is just the paycheck that feeds my family. Great! There's nothing wrong with you! You outnumber the programmers who view it as an artistic endeavor and self-actualization.
Group 2: programming-is-my-vocation -- the minority -- The programmers who got into as kids and find joy in side projects after hours & the weekends.
It's not enough for these 2 groups to peacefully coexist. It's also not enough that Group 1 outnumbers Group 2. It's also not enough that most cog-in-wheel corporate programming jobs don't even value Group 2's enthusiasm for programming.
No, Group 1 is not satisfied with the above advantages.
Group 1 is very annoyed if Group 2 programmers prefer working with other Group 2 programmers. G1 derides G2 as psychologically defective or unbalanced. E.g see HN poster (gyardley)[1] describing them as an "obsessive wretch" and "not an asset". Toxic indeed.
You are way off base here. The issue here that group 2 by it's very nature, being passionate, is way more vocal and outspoken about the issue than your group 1 people. It's not a problem that group 2 people want to work with other group 2 people so far in that it doesn't affect group 1 people but that's not how it works. Your group 1 people generally don't care who they work with so long as they can do the job. The problem is that by being far more vocal they affect things like hiring, and who gets promoted which does negatively affect group 1 people. Regardless of the size of the two groups you have described if one is making it harder to advance for the others while not being provably better you're going to have a problem. And that is why you see a lot of people arguing against this mindset, because it IS toxic, and creates a situation wherein only people who have demonstrable interest in programming outside of work can succeed and advance.
Also This mindset eventually can backfire on even your group 2 people because life happens and just because you have the free time, energy and motivation today to work on projects outside of work doesn't mean you will later when you have a family or health issues or any of the myriad other things that can come up.
>Your group 1 people generally don't care who they work with so long as they can do the job. The problem is that by [group 2] being far more vocal they affect things like hiring, and who gets promoted which does negatively affect group 1 people.
Well, G2 people have an affinity for other G2 people. That's human nature! That's not toxic. Look at the various reasons given by G2 posters in this thread: they enjoy a work environment with other G2 people. Just as one can prefer having a comfortable chair or closed office, a G2 can state honestly that they would be happier with other G2 colleagues. Just because that has an effect of G1 not getting hired does not mean it's toxic.
The analogy I like to use is a music band. If they're looking for a guitarist who's passionate about his instrument and music, the guitarist-just-a-job who has apathy about the music will not get invited to join the band. Maybe the apathetic guitarist can technically strum a C chord as well as the passionate guitarist. That's not enough. The band having a preference for the passionate guitarist is not being toxic.
Yes, for many G2 programmers who started as kids... programming/playing with the computer is a very similar intellectual high to a teenager exploring a guitar. Programming feels like fun artistic expression and not "work" or a "job". I think many G1 programmers really don't understand that. If they could view G2 programmers as band musicians, maybe they would have more empathy for the passionate programmers having a preference for like-minded people.
Literally nothing in your comment rebuts my argument. It's not an issue that you want to mostly be with other G2 people. That's perfectly fine and people understand that. It's an issue when you're desire pushes all the G1 people out of the work place.
I'm not going to think of programmers as musicians because they're not. They are employees of whatever company. They are there to do a job. It's great that you want to work with like minded people but if that desire means that qualified G1 people can't get hired at your company that's a problem. If your desire means that g1 people can't get promoted that's a problem.
As a thought experiment replace like-minded people, with people of the same race. Or people of the same gender. Or people of the same religion. Do you see the problem now? A mindset that excludes some large percentage of people based on arbitrary standards that has nothing to do with their ability to do a job is always going to be problematic.
Side note if you lead with "looking for passionate" you're already misconstruing the issue, because what a company should be looking for is "able to do the job to whatever standard we've set"
>wherein only people who have demonstrable interest in programming outside of work can succeed and advance.
Nobody in this thread has said this. Maybe your misunderstanding of the other side is part of your frustration on this topic?
Some have said that the self-taught programmers were better. Some have said passionate programmers were more driven to stay relevant in a changing field. Some have said they learn more from coworkers that developed interest in programming outside of college and work.
You may disagree with all 3 of those statements but none them are about dispassionate programmers not being able to succeed.
>It's an issue when you're desire pushes all the G1 people out of the work place.
This has never happened. In fact, the opposite has happened. G1 is the overwhelming norm at most businesses. To repeat -- most programmers do not view coding as a vocation. G1 programmers already fill most jobs slots.
The idea that the minority of G2 programmers want a work environment with other G2s and this is hurting G1?!? That is a complaint that's way out of proportion to reality. Literally.
Also, I'm not sure why hiring heuristics that negatively affect G1 somehow has a higher moral standing than heuristics that negatively affect G2 programmers. What about the opposite situation? E.g. G1 people say being well-balanced with non-programming activities helps them be a "better programmer". Great! Let that belief be a guide and don't hire G2 programmers since their excessive interests in computers actually makes you believe they perform worse. They are not assets. (See my previous cite to HN thread for example of this.) In those cases, G1 wins over G2 in getting the job.
>They are employees of whatever company. They are there to do a job.
The founders and many programmers would like the daily effort to be "more than a job" if possible. Sometimes, that's not possible (e.g. Walmart cashier). However, with programming, some do try to optimize for a better work environment.
>with people of the same race. Or people of the same gender. Or people of the same religion. Do you see the problem now?
Those race/gender examples weaken your argument. Having a preference for people with similar intellectual dispositions in programming is very aligned with Martin Luther King's "not being judged by the color of their skin, but by the content of their character."
>arbitrary standards that has nothing to do with their ability to do a job
Then this discussion has no resolution because in this thread, many have written about experiencing the opposite. Instead of it being an "arbitrary standard", it's been a positive correlation with performance on the job.
>what a company should be looking for is "able to do the job to whatever standard we've set"
Ok, many programmers in this thread said they prefer colleagues who enjoy computers+programming as outside interests. That's the standard that's been set. Many companies want to attract those programmers by hiring G2.
>No one expects a chemical engineering 1st year student to have mastered
Neither ghaff nor I wrote anything about kids "mastering" the STEM topics before college or the first job. Therefore, that higher standard stated by you is a strawman.
I thought ghaff was talking about STEM side projects which is certainly something within the abilities of teenagers without mastery of programming. That's what my reply to him/her was about and how "playing with science" is not unique to programming.
No one would be expected to do meet those high standards, as you say. No one would be expected to be experts in basic chemistry by their first year of college.
Yet in this very post, there are countless examples of people saying the best programmers were the ones that knew it all before college, who didn't need college, who put in the time to learn before college, etc.
No other field is this expected. That's the point.
Playing with science and doing small little cute fun experiments is a lot different than me teaching myself productive front end development at age 16. I don't expect other 16 year olds overall to do as I did. Nor do I judge people if they didn't.
>in this very post, there are countless examples of people saying the best programmers were the ones that knew it all before college,
Nobody in this thread has said that programmers should "know it all" before college. You're injecting conditions and standards (like "mastery") that no poster actually wrote.
>No other field is this expected. That's the point.
This isn't true. You can see coaching advice for electrical engineers to update their resume with any DIY (do-it-yourself) electronics projects that would demonstrate self-motivation, passion, etc to potential employers. In that respect, it's not much different than computer programming. Do electrical engineers get jobs without any personal side projects?!? Yes, of course. Same as computer science -- many programmers get jobs without side projects.
In both scenarios, it isn't absolutely necessary but it's a way to stand out from the crowd.
Yes, there's often a level of interest beyond "Hey, I liked this class in high school." But I'd still argue that the computer science space is unique in that there's a fairly widespread expectation (as seen in these threads) that it's expected to be some sort of passion indulged in since childhood. To the degree that a lot of today's university CS programs don't effectively accommodate those without previous experience. As a mechanical engineering major undergrad, I can assure you that I had no particular experience in the area prior to college.
That's exactly my point: there is an expectation associated, especially from the HN echo-chamber, that you've been passionately programming since your early teenage years and that if not you're just a pretender looking for the salary and can't solve problems.
> As a mechanical engineering major undergrad, I can assure you that I had no particular experience in the area prior to college.
I'd say this is true of most people entering college. Hence we have introductory courses to learn there.
It's a shame that so many people on here and elsewhere simply want to discourage people from following an interest simply because they discovered it later.
This field changes so much that if you aren't passionate and investing in your skills continuously, you will find yourself obsolete or in a non-technical role within 5-7 years. Think about that. How many years does it take just to become technically proficient?
Why do you need to be passionate to improve your skills continuously? Why does being passionate guarantee you are going to develop the right skills rather than latch on to an academically-satisfying yet commercially-useless niche?
Because the academics ultimately drive the commercial, there's just such a delay between the two that the relationship isn't always obvious. Just take a look at Java, one of the most widely used programming languages for commercial development. It's hardly cutting edge, but if you step back and look at the way the language has evolved it's slowly been integrating all the design choices that have come to the forefront of academia. Generics? Check. Lambdas? Check. Streams? Check. Reactive design? Check. Non-nullable values? Eh, sort of, half marks there. Immutability? They're working on it.
I'm not sure about "passionate" programmers, but programmers who enjoy programming are generally always on the lookout for new trends, new tech, new libraries, and even if you aren't using those things, being aware of them is massively useful. If you're relying on the business and your coworkers to drive your skill improvements, then you're going to stagnate, guaranteed, because the business doesn't care at all about new technology and has no desire to improve or change anything, and your coworkers will only care if (shock) they enjoy programming.
When you put together a team of 9 to 5 only in it for the paycheck programmers, what you get is a snapshot, their combined skills and technical knowledge will be the sum total of exactly what all of them know when you hire them and it will never improve. Putting together a team of programmers that enjoy programming and are doing it not just for the paycheck but because they enjoy the craft gets you a constantly improving team. Their skills stay fresh and they're motivated to improve and keep your tech relevant and modern, which ultimately saves you in the long run from having to face massive rewrites of old creaky systems, or ending up stuck trying to hire massively expensive developers to work on ancient deprecated technologies.
"Passion" the term definitely needs to be retired. It's pretty much a dog whistle as you say. However, whatever you want to call it, I do prefer to work with people who have both a high work ethic and an intrinsic interest and excitement about their work. It's absolutely more fun to have people to "geek out" with than not. In the grand scheme, I think we spend too much time at work to not try make it as enjoyable as possible while also still doing a good job. So I guess to your question of who gives a care if a coworker is boring: I (and I think lots of others) do...
> Do they have the work ethic and professionalism to continue to do so?
It is a rare person who has enough work ethic to force themselves to use their own free time to improve in a field they don't have any passion for. If that weren't so, we'd see a lot more self-taught physicists, mathematicians, and other STEM people.
> The vast majority of people, including those who excel at their respective fields, don't love their jobs.
People who excel in their fields don't love their jobs? As kids nowadays say, "[citation needed]".
Not sure how the industry may define passion, but for me it's a constant drive to develop one's skills, improve one's output, and an interest in all these things outside of the hours you get paid to be interested in them.
I've hired good developers who had this type of passion, and good developers who lacked it. But I've yet to hire a truly great developer from the latter camp.
It seems to me this is true in just about every industry, those who have devoted the most time and energy to a skillset tend to be the best at it.
People can also gain more interest even if it was "just a job" before.
I fell into IT and struggled with feeling overwhelmed the first year or two but once I found the things within that field that fit my personality, that's when I felt more comfortable and could push myself more and ignore the BS that I didn't really like.
I completely agree about the "passion" thing. You can develop curiosity and interest about anything.
Thank you for mentioning this "passion" problem we have. I did a count once, after I nearly became apoplectic after reading yet another job ad that looked for a "passionate" programmer.I counted the number of times Passion was mentioned in job ads for programmers on Find Bacon in NYC. I compared it to the number of times New York itself (where these jobs actually were) was mentioned- and whoo boy! It was something like 4 times as many mentions of the word passion. Wtf does that even mean? That someone foregoes all else like a priest while they code up liked lusts for your company? I worked in the fine arts before, and no one mentions passion... ever. It kind of goes without saying that you have a work ethic if you can play your instrument at a professional level. We all understand the effort that requires. This love of the word passion would be a red flag for me, if it were not like the word "like" used to be for tweens. I sure wish we could all take a break from it and put some actual psiion into understanding what we actually need from employees. The usebof this word speaks to a need to hire young people who have not yet learned their worth and to set boundaries. It is like the hiring equivalent of a middle aged Humbert Humbert trying to lure a sweet young thing with a copy of Rilke's Letters to a Young Poet. Cannwe all please agree to a break from this word?
> The best developers I worked with are the self-taught guys/girls who learn on their own before they even hit the college
I think this is the crux of the issues I had with bootcamp candidates. They were reasonably strong in the areas that they'd been taught, but there were gaping holes in their knowledge wherever they hadn't been taught. They could explain how to build a site with a Node backend and an Angular front end, but they couldn't explain why any of the decisions they'd been taught were good ones. And there were fairly basic concepts that were completely alien to them...of the 20 or so I interviewed, not one had even heard the term 'load balancer', let alone could tell me why I might need to use one. They had no notion of 'threading' or what it meant for a piece of code to be 'thread-safe' because they were only taught Node and its concurrency model. Even then, not one of them had heard of 'nextTick' or understood the event loop beyond the fact that it would call their callback function with the results. Their experience felt like a facade that was designed to seem impressive than it actually was. And all the areas where a developer with a traditional background would have thought, 'huh...I wonder how that works?' and then spent 2 hours figuring it out were completely unexplored.
This is why I think developers coming out of college are significantly more likely to be better at software development...not necessarily because the education they got in school was better, though I do believe an education starting with first principles and teaching you to figure out the solution from there is a better approach, but because the people that choose to study that in school are self-selecting for curiosity in the subject. They're the ones that hit something they don't know and go learn it rather being told what to learn. And they're the ones that spent at least 2 years following those tangents to get a more well-rounded education. Because any developer who only knows what they've been taught in courses, be they bootcamp or a traditional CS degree, is not going to have what it takes to learn on the job.
I recently wrapped up teaching a bootcamp course. In the timeframe for teaching bootcamp students, there's no realistic way to cover load balancers or teach the event loop holistically
You underestimate the time a self-taught developer would spent figuring these things out. I'm self taught, and though I think nothing of it I easily spend 4 hours on trivial things -- it had never mattered until family obligations made it obvious that I needed to cut down since I was also teaching on top of my full time job.
I started teaching the bootcamp precisely because I disagree with the mentality that junior web developers need to understand load balancers or the event loop or any number of other things. These things WILL come to experience, and all you need to get started is grasp the basic syntax and be able to follow the execution path of anything you write.
It's a job, as much as people like to believe that it's a craft, and many other people are fully capable of doing this job even if their decisions look different from our own. Most of my students are at the same place I was when I landed my first Jr role, a handful (about 20% of the class) are far ahead of that point.
I'm not impugning bootcamps or claiming you should be teaching those concepts. I'm claiming that it takes years of independently exploring and learning concepts to be qualified for this kind of work. Most of the developers I hire and work with have been doing this kind of exploration since they were teenagers, if not before that. By the time Node, Angular or most of the technologies taught in these bootcamps came out, they would be comfortable reading docs and just figuring it out and wouldn't need a bootcamp to teach it to them.
It's an unrealistic expectation to think that people can go from zero to professional in such a short time. I honestly don't care if a junior developer knows those concepts. What I care about is that they know something other than what they were taught in the bootcamp. Show me some independent exploration that you did that wasn't required for the bootcamp which leads me to believe you can do more of it. I can pair a junior up with a more senior developer some of the time, but most of the time they're going to have to flail around and try to figure it out by themselves and I want to know that they can do it based on nothing other than documentation, trial and error rather than needing their hand held.
Except most university cs programs don't teach any of those things either. I went to an excellent school for CS and we covered basically zero web concepts in our core CS classes. Sure we learned threading, but not any model that someone would actually use in real life making it at best primer for future learning and at worse worthless. I think it's an unreal expectation to think new devs from either Bootcamps or college are going to have a solid foundation on anything more than how to use a language and a few other domain concepts. CS grads don't know anything about the web or mobile generally but can learn. Bootcamp devs probably are missing database, and algo knowledge, but I don't think that stuff is any more difficult to learn either.
I think you misunderstood my meaning. Of course CS classes don't teach you that stuff. The point isn't that CS classes prepare you for the workplace any better than a bootcamp. The point is that the intellectual curiosity necessary to go learn things on your own is the only thing that prepares you for coming into the industry and staying relevant once you're working in the industry. And those that are curious about computers from an early age are the ones that end up in CS classes or getting jobs in the industry without a degree from a university or bootcamp. The education CS grads receive in school is mostly bonus principles that help them make sense of what they learn on their own and isn't really necessary.
I guess my point is that the people going into these bootcamps, from the ones I interviewed, didn't seem to be people with that curiosity who had taken the time to learn a bunch of stuff on their own. They seemed to be people that wanted to quickly learn to be a developer. And it's perhaps possible to cover the part of a CS degree that's actually applicable in the workplace and a few technologies in the months that students participate in these bootcamps. But it isn't possible to cover the years of independent exploration that most CS graduates did both before, during and after their degrees. That's the bulk of what makes someone qualified to work in the industry. And there aren't really shortcuts around that learning process.
I agree with this somewhat. The technology is the tool but the principles should be the first step.
This was said over on /r/sysadmin when people were discussing where to start with Powershell scripting and the top answer was to get a basic grasp of OOP first as a foundation.
I agree with all the points you made, except for a part of the third one.
This "started coding in middle/high school or college" is a misleading metric since it assumes everyone has equal access and support to learn that way.
As some one from India who never had own computer until finishing college (the early 00's), along with no internet or cell phone, I find it hard to accept/respect those people who gloat about how early they started coding.
I always assume there are thousands of kids in the US who were/are not as lucky as the kids who started coding while they were in their diapers.
People/companies in US love to talk about their efforts to fix diversity, but without fixing this attitude of "earlier you learn, better you are" attitude, no amount of throwing money will fix it for the true diversity candidates.
> but without fixing this attitude of "earlier you learn, better you are" attitude
This mindset seems to work rather well for more objective areas like athletics. I don't see any reason why an intellectual pursuit like programming would be any different.
I don't know if it works. I dont know why it should be the same.
But at least, in athletics, there's no charade of trying to fix the gender/race bias by throwing money at programs that make other's catch up so that they can claim "equality".
Most Marathoners and NBA players often are African or have African ancestry. And no one says the same team should have an equal number of <insert race/gender here>.
IMO, humans are adept at learning intellectually for a much longer time, compared to improving physically in 'objective areas' like athletics, which needs to begin very early in a human's life.
1. Athletic performance is easy to measure. Especially for individual sports (track and field, gymnastics, weightlifting) the numbers are the only way to compare athletes. Not so for programming. If someone invented a way to definitively judge programming ability today they'd become very rich, very soon.
2. If we assume that mastery of programming follows a sigmoid-curve (not an unreasonable assumption, IMO) it means that the ability difference in "coding for X years" and "coding for X + 5 years" becomes nearly indistinguishable for some value of X, for people of roughly similar innate ability and drive to improve. And if you believe in innate ability, then there will certainly be people who came to the field late and caught up with, or surpassed, less-innately-talented colleagues who have been programming longer.
3. One of the reasons that starting at an early age is important in athletics is because peak performance is harder and harder after you turn 30. The "growth" phase has to be therefore significantly accelerated. There's also evidence that for technical sports requiring motor coordination (eg. soccer), learning young is better. Whereas people can code at peak level until the day they die, assuming no other illnesses.
> See anyone you can think of from the 60s and 70s like Ken Thompson and Dennis Ritchie.
Ken Thompson had a MS in EE/CS and Dennis Ritchie had degrees in both physics and mathematics, all of which are far more difficult than programming. Most of the other great names of the '60s/'70s have similar backgrounds, invalidating your point.
It's also unfortunate that everyone defaults to measuring the years that have elapsed since someone's first line of code, instead of hours invested.
"N years experience" loses value as a measuring stick when there are probably 2 orders of magnitude separating how much code the most passionate and least passionate developers wrote in that time frame.
I don't think it's misleading at all. It is unfair, it is an outgrowth of privilege.
The issues with diversity, prejudice and bias would be much easier if there weren't cases where something was both unjust and true. Software development is one of those activities where experience is helpful, so those who start earlier are generally better.
Except that's all anecdotal. How do you measure how good someone is at programming? Have there been any studies comparing intro age to programming with future performance? Anecdotally, I know plenty of people who have been programming since elementary school who are terrible compared to someone who learned in college.
And it's not hard to guess why. Just because you've been programming for a long time, doesn't mean you were doing it correctly, or even understood what you were doing.
A 93% failure rate is absurdly high, and probably more indicative of an inadequate hiring process than "bootcamp grads are all dumb lolz". Are there any examples you could share of relevant interview questions that this group faked their way through, but later were revealed to not understand? Have the hiring managers since been mentored on how to do a better job vetting candidates?
This was more than 2 years ago, I don't work there anymore. But to my best recall, the interview process was pretty straightforward, mostly revolved around basic programming knowledge (we knew we were aiming at junior devs). Basic programming questions (what is an object, an array, etc..), a few question on to approach a particular problem and lastly they were presented with vanilla JS file, with bugs and things that could be improved.
No algorithms, or data structures or complex problems to solve. Something that I would include if these were fresh college grads or senior developers with extensive background.
Again, I didn't mean to call anyone dumb, I don't think these people are dumb at all, they were just bad/fast trained.
>> presented with vanilla JS file, with bugs and things that could be improved.
Uhhh that's really difficult in js even for experienced devs. Way too much non deterministic behavior. I hope this exercise came with tests and a working debugger.
For #3, I know a lot of people who started this way and then used a bootcamp to build modern skills. To me, that's a really solid combo. Having a bootcamp be your first intro to the field is a much tougher road.
This is a cool idea. Even though I've got close to 20 years under my belt, I could almost see myself going to one of these bootcamps simply to quickly update my skills to today's New Hotness (web development or ML). Wonder if it would actually be useful.
As someone who both interviewed bootcampers, and also partnered with a local bootcamp (IronYard) this is pretty much exactly my experience. The bootcamps can take someone who had an interest in programming before hand, and give them a fast leg up to get into programming professionally, and that's great. But the vast majority of people in these programs are just there because they heard you can make a lot of money as a programmer and have no real interest, or talent with programming, and it shows in their work.
India had similar code academy type institutions in the 90s (don't know if they still do) and they gave pretty much the same results. A very small percentage who "get it" and could think their way through a logical problem in a logical way; and a majority - those there strictly to find the path to a well-paying job - who could write code to the exact specification you provided, but with no independent thought.
Only difference is that then, the token technologies used for study were out of MS's desktop stack.
Source: worked with lots of outsourcing/offshore partners out of India during that time...
edit: I should also add that in the US the same could be observed: uptick in CS grads who only started out in it for the money, had no real interest in the actual building blocks they were given -- and were predictably uninspired in the workplace.
The percentage of 'good' programmers was higher, but that was only because there was a 4-year barrier to entry vs ~16weeks-1yr for the tech schools in India.
I agree with 3, the disclaimer being that I myself am self-taught. However, in college and now 7 years later in my career the best problem solvers I met were self-taught. My senior project lead, who's younger than me, doesn't have a CS degree like me but constantly impresses me by his breadth and width of knowledge--more than my own in many cases.
For almost everyone else I've worked with it's just a job. No Github account, no personal projects, no dev environment setup on any home computer.
Do you still interview front end developers? It is absurd that, as a bootcamp grad, I am trying to get a potential opportunity from you in a thread that vilifies bootcamps but I wanted to give it a try anyway. I do have some experience and a decent portfolio. I would love to provide links and resume if you could shoot me an email at timon.park@yahoo.com
Hell, I've been doing this for 13 years (professionally, more like 20 total) and at this point I only care about the money too. Everything else about this industry is not great, honestly.
Do you want to be less "boring"? Do you work well on your team (if you're on one)? Are you valued by your team/company? Are you worried about future job prospects?
If you're happy with your current situation, forcing a change isn't going to suddenly make you interested in those changes. If you have legitimate interests, explore them. If you don't, see what catches your eye here on HN and other places and read up on them, seeing if anything naturally does.
I didn't mean to say ALL of them obviously, I just meant to say that a lot of devs who only learned to code in college, usually don't code for fun, just code to get the job done. By no means are they bad programmers, in fact they are good coders, they just lack curiosity and some creativity. Is like IBM vs Apple in the 70s if you know what I mean :P
That's too broad a question; you'd need to specify "front-end developers" in the context of their primary focus, first.
Are they game developers?
Are they working on enterprise apps?
Are they working on lead-gen landing pages for marketing companies? Data visualization? Accessibility-focused?
etc...
Front-end is becoming increasingly specialized to a degree.
1) Most of the bootcamps teach the basic of front-end, and a lot of them, teach by doing without explaining a lot of basic concepts. They are basically money grabbers and throw these people out of the door as fast as possible to get their money back.
2) A lot of the students are in for the money, not for the love of the job. Sorry, but it's true. I don't mean to include everyone, but out of 30 students, only 2 kept working in my previous company, they weren't good developers, but they loved the job and kept learning and improving themselves. Nothing wrong with pursuing a good paycheck, but in developers world in order to keep being relevant in the next 2/3 years you need to keep sharping your skills.
3) The best developers I worked with are the self-taught guys/girls who learn on their own before they even hit the college. The most boring developers I work with, the the ones who only learn to code while in college and never developed any interested to learn before that. But the most horrible devs I work with came from boot camps. Not their fault, it's just how bad these bootcamps are.