I have met many programmers that don’t like to code in their spare time, and that has reliably revealed them to be sub-par developers.
I loathe this attitude and find it absurd. Imagine saying the same thing about aerospace engineers, or physicians.
If you wanted to say something like “the traits that make a good developer include a boundless intellectual curiosity, and this can manifest itself in coding as a pastime or any number of other active learning hobbies” or something that’s fine, but please stop demanding that we all work outside of work.
Yeah, it’s the same nonsense that says every developer needs to have an active GitHub (on which your abilities will also, of course, be judged). Some people (like me) like to program in their spare time, and do have an active GitHub. But this says nothing at all about how good you are at programming. A very good friend and coworker of mine is a much better programmer than me (we’ll often get to the same code, but he does it a lot quicker and easier than I do). He has a GitHub, but there’s barely anything on it, and he doesn’t often program in his spare time. You know why? He’s married, and has two young children that require a lot of his time and attention. If he were judged solely on his GitHub with the mindset mentioned above, you may think he’s a terrible developer not worth your time to hire, and thereby miss out on a really skilled and talented person.
It’s another sorting mechanism by which groupthink is enforced. It’s “culture fit” nonsense, no more no less, and not in any predicative of any actual ability to do the work required, unless that work is furthering the given culture.
While I agree with your premise, I think of it a little bit more softly: nobody really knows precisely what makes for successful workers of various kinds, so people tend to select for “similar to myself”. When those actually-squishy, please-more-people-like-me criteria are treated as objective, that’s a really unpleasant cultural complex.
It’s not predicative but it is predictive! The set of people interested in programming in their free time is better on average than the set that isn’t. For starters because they do more of it, also because they’re more engaged when they do it.
If we refine this to “the set of people calling themselves programmers who are interested in programming in their free time”, etc, then I don’t think that’s true. I think this is a fair refinement, since 99% of the population can’t program, so your assertion is then true but not for the reasons stated.
I think that the set of programmers who program in their free time is going to have a higher percentage of people who can at least write code that roughly works, simply because they’ve got more practice. There will be many more programmers in the latter set and some of them will produce a far higher quality of code than the median in the first set. I state this because many of the people in the first set are younger and less experienced programmers, not yet with families, who may be brilliant technically but haven’t yet learnt enough about maintainability or robustness not just against external vagaries but against less skilled programmers making unwise changes and catching them early.
So “programs in their spare time” is a filter which will reject many people you want, but those who do get through will at least meet a certain minimum bar. If you’re not prepared to put the time in at recruitment to test beyond that, then you’ll get a monoculture and it may work for you. You can win in business/recruiting with this strategy. That doesn’t mean it’s wise.
This then leads into broader issues of what should make up a team.
This is an important part of the interviewing equation too: unless you really know what you need quite exactly, you’re using tests that are inexact: tests for things that correlate with or are proxies for the really desired quality/skill/capability. And when you find a good candidate, then you hope(!) that the correlation holds.
I think that inability to accurately define the set of needed capabilities and unwillingness to train people of evident aptitude are the two cardinal sins for those who “can’t hire enough qualified people!!!!”; their punishment is they have to struggle on, somehow, staffing up with a subset of the people who could do the work.
Exactly - in this and so many ways, everyone is different. There have been times when I have coded quite a bit outside of work, however for me this has often corresponded to my doing a job with relatively limited intellectual stimulation or new learning. I find myself now learning several exciting new technologies at my job and working in a relatively fast-paced environment where I am learning and being productive most of the day, most days. I don’t have a whole lot of mental energy left after a fully realized workday to spend hobby coding, but I am the best at my job that I’ve ever been.
Agreed. I used to spend a lot more free time on programming-related hobbies. Then I had kids. If anything, my rate of programming self-improvement has gone up with less time spent on it, because I focus only on the most valuable things, not every shiny new toy that comes along.
Of course, I also view it as part of my job’s responsibilities to explore different programming approaches as appropriate, so I get a decent bit of exploration built into my workday.
“the traits that make a good developer include a boundless intellectual curiosity, and this can manifest itself in coding as a pastime or any number of other active learning hobbies”
That’s a good way to put it. Similarly, when hiring technicians for our optical lab I have found asking if they change their own oil in their car has correlated with good fits for the job. It’s not that I wouldn’t hire someone who didn’t, it’s just that doing that lines up with some of the things that made someone excel at that roll: hard working, mechanically inclined, and good with their hands.
When I hire people I ask them if they can do a switch hardflip. It’s not a dealbreaker but it definitely shows technical ability.
Learning is self-reinforcing. Spending offhours learning reinforces your on hours learning. This advantage accumulates over time, it becomes obvious over time.
A couple of comments on this:
1) As a developer with experience from the OS-level up to front-end applications, I’m constantly frustrated that many of the “full stack” roles I find in the bay area really only mean “front-end and service layer”. I’ve been trying to experiment by calling myself an “all stack” developer to see if it would affect my inbound recruiter streams, but still it seems to be that a lot of the people looking for talent are willing to hire developers who are experienced in only a sliver of the stack (and yet still call it “full stack”.)
2) The author mentions something interesting with respect to the term “hacker”:
Today the word has a negative connotation, but in the early days, it referred to a person with a certain attitude towards technology
My experience here in the bay area has been the exact opposite. “Hackers” used to be considered criminals and part of the extreme counter culture back in the day. Today, especially among startups, the word “hacker” is used to describe a certain kind of scrappy developer who can “hack” things together on a tight budget and in no time; for obvious reasons this is considered a highly desirable thing for small companies trying to make it big, and so you’ll see it in the job listings “looking for hacker to help disrupt X” and even in recruiting tools such as HackerRank.
Interestingly enough, this use of the term “hacker” has seemed to have shifted meaning from someone who did read their sound card manuals and really took time to figure out how it’s working, to now referring to someone who gets things done quickly without really know what they’re doing (aka “hacking” something together). IMO this might be what the author refers to as a more negative connotation, as young developers aspiring to become a “hacker” may think that it is less necessary to learn why or how, and instead to focus on the what and when.
Whenever I hear someone refer to themselves as a full stack developer I am always tempted to ask them if they are designing a stack-based instruction set or if they prefer to build a register-based one, or whether they think it’s wise to base their next system on OpenRISC.
I wish people would use the old term “web developer”. Its generally what people mean by full stack ( leaving out mobile).
Today, especially among startups, the word “hacker” is used to describe a certain kind of scrappy developer who can “hack” things together on a tight budget and in no time;
Maybe “hackathons” have something to do with that changing perception. It sounds about right, help a (for profit) company solve their problems for a slice of pizza.
It certainly would contribute, good point! I mean a hackathon is literally entirely based on the idea of minimizing time while maximizing technical output. Another interesting observation of mine while participating in hackathons: the emphasis tends to be on building something to work for the duration of the hackathon, and no more. I believe they call this an “minimum viable product” (MVP, for short) in the industry. I personally like to call it MVP as in “mostly verbal product”, as is the typical vaporware at these events ;)
It is amazing how a full-stack developer never seems to get paid the same amount as an admin plus a backend dev plus a dba plus a frontend dev plus a designer.
I’ve never actually met someone who does all 4 of those things. Usually the person wearing all those hats has: run apt-get install db, created a table, queried the table with a script, dumped the results to html.
That is all many small companies need.
Is this sarcasm? A single person works 40 hours a week, they’re not going to get paid for 4x40…
Depending on the value they provide (and how well they can negotiate their salary) they might get paid 1.5x or 2x, but I’d never pay 4x to an employee just because they have 4x the skills. Employers pay per value and it’s difficult to provide 4x value working the same amount of money.
Of course, if they do, then they’d deserve to get paid 4x.
And then one day the guy quits and six months later you realize you’re now paying four guys to replace him and you realize also that it was a damn good deal when the guy was there. Don’t see this often, but i do see it.
works 40 hours a week
I’m not sure how much that is the case, especially at the companies who want full-stack devs. :|
Olivier here has the right idea: you’re gonna underpay that person, they’re going to leave, and then you’re going to be scratching your head going “well golly gee how could that happen…they weren’t worth 4x”, and then having to hire 4x to replace them.
(Or, more likely, you’ll end up bleeding cash to one of the many PaaS or SaaS providers that have stepped in to make up for bozos in business who can’t bring themselves to pay developers what they’re worth.)
Developers share some of the responsibility here: If they want to get paid more, they need to deliver.
The number of “expert” and “full-stack” and “senior” programmers who don’t get anything done have really dragged the mean salary down, and make it really difficult for the COO office to justify hiring someone in at 4x above the mean – if they don’t work out, then not only are they out the cash, but everyone else feels the disruption of someone coming in with an inflated title. A better strategy for management is to scratch their head and say golly gee.
If you’re that guy, and you feel like you’re being underpaid, you can talk to your boss about getting paid more, and about demonstrating your value and positive things like that, and you can show it will take more than a year to be replaced, and all the deadlines will get missed in your absence, and all that negative stuff as well. Respectfully. However he (likely) has a budget, and he himself will have to ask to increase it in order to pay you, which means you will be most successful if you give him the tools to have that conversation.
I’ve done this, and more than 5x’d my salary in doing so. I’m happy to talk to you (or anyone) privately about how to do this specifically in your situation, because I don’t want programmers to turn caffeine into code, and I don’t want the “senior engineer” to not know anything about the problem domain; I want programmers to get paid more, and I think tilting at windmills isn’t going to do it.
Or you can cut and run, and maybe get a 10% boost in salary. It’s probably easier, and then maybe you can write a blog about how underpaid you were, and how much better things are at your new gig.
Good points sir, and I think you have a lot of useful stuff to teach here.
My experience, in young startups, is that even with a clearly-articulated argument cheapness wins out. This could be, and I suspect is, because of the folks I had the (dis)pleasure of working under.
You’re right, but you should know why: I say this with as much respect as I can type, but maybe there’s a guy who’s 90% as good as you, and if he works for 20% less then the boss might take the gamble – especially if it’s not really going to affect his mortgage.
My advice is to move house, because there are companies that won’t jerk you around, and if you learn how to ask for it, will pay you what you deserve, just understand that they don’t post to cybercoders or deal with the linkedin recruiter farm.
Not really arguing here, olivier and you are right. However, I haven’t seen many people switch places because of the salary. Maybe it’s because I live in Spain and all salaries are crap, you’ll never make a jump towards a new job which pays you 2x or 3x.
If an employee jumps ship because they feel underpaid, trust me, being underpaid is the excuse. An employee who really wants to stay first tries to get a raise or other compensations. Leaving a company unilaterally is usually the sign of other issues.
Generally people are paid according to their experience level, and someone who has competency in system administration, backend business logic, database architecture, front-end technologies, and graphic design, will not be experienced in any of these things, let alone all of them.
For many, very real things, competency is enough to make a software company, but a real expert in all of these things absolutely is worth five, and can command the salary if they are indeed credible.
Counterargument: I haven’t seen a lot of companies looking for full-stack developers that are also willing to pay the 5x salaries for true experts. “Full-stack” is increasingly a thinly-veiled lie for “We have a lot of tech stuff done quickly but can’t/won’t hire enough people to make that happen”.
I see your point about relative experience levels, but I think it leaves out a big part of the calculation–often the overhead of coordinating multiple experts is way worse than just paying a generalist what they’re worth, and the experts may lead to the design of complicated systems because they lack the breadth of perspective to do full-project optimization.
Perhaps you misunderstand me: All I am saying is that the salary of an employee is roughly proportional to the depth of their experience, not their breadth. We may wish it to be different, but it is not, and it’s not just because five experts each with twenty years experience is worth more to a company than one generalist with twenty years of breadth,
However the effect you’re referring to has very little to do with expertise: Many entrepreneurs view building a company as a numbers game, and only want to hire a few hacks, roll, and hope to get lucky.
But if they are halfway comfortable with any of these and can connect the dots between the two, the combined experience is worth much more.
There are indeed times where the devil is in the details, but the rest of the time, five experts will be much more effective than one smarty-pants.
I’d argue that having a team of a few specialists + a generalist is often a good idea; I’ve found it priceless to be able to bounce ideas off of someone who’s not necessarily an expert but also not a total noob.
I see the pattern that many experts just don’t have the flexibility to think outside of their box, I disagree. We often forget that people cannot be replaced in short succession, when requirements change.
Okay, so people who call themselves experts aren’t? Or maybe I don’t know what you’re disagreeing with.
I fundamentally don’t get why anyone would think they deserve 5x the salary when they don’t have 5x the skills and experience.
I mean, I sometimes cook breakfast, does that “generalist” experience with being a chef mean that I deserve another person’s salary?
And there’s your problem. You seem evenly distributing skills as not seriously practicing those skills.
“Generalist experience” as a chef would mean that you know a wide array of skills, from cooking to grilling to baking, and while you don’t excell as a baker, you can produce a fine meal with a side of (very good) bread without extern help.
“Seriously” practicing sounds sophomoric and I still don’t understand what you disagree with. I don’t think I’m distributing skills or anything else, I’m saying a guy who says he has programmed for ten years who splits his energies between databases and user interfaces, doesn’t deserve the sum salaries of the two guys who have each programmed ten years, one on databases and the other on user interfaces.
If you disagree with that, you need to explain why succinctly and directly, because that this hypothetical programmer might be worth more than one of them isn’t (in my opinion) relevant, since “full stack” developers tend to make more than “front end” developers.
I hate this gimmick of a title because they surely don’t deserve it. I reserve that for people like Niklaus Wirth who do everything from apps to compilers to OS’s to hardware itself. They know the full stack. I elaborated here in a prior comment: