McKenzie (original article's author) worked probably a decade outside a major center of tech R&D before taking a job at Stripe. A lot of his advice is written from that viewpoint. It's valuable because a lot of the world operates as he describes.
I think the big lesson is that life inside industry clusters (finance/media in NY, Hollywood, Silicon Valley, oil and gas in Houston) is quite different from life outside. In industry clusters, jobs are way more specialized, standards are higher, and "geek skills" pay off way more. A few jobs ago, we engaged a consultant for decent money to tune our postgres implementation. I can't imagine that job existing, or paying that well, outside of a major center of Internet software development like SF/SV. I'm sure there are analogs in oil and gas, or any other clustered industry.
> I'm sure there are analogs in oil and gas, or any other clustered industry.
My dad was the ops officer on an Air Force base in the 1960s. His job was to keep the base operational. The Vietnam War was ramping up, and the AF's need for transport airplanes outstripped their jets, so they pulled a bunch of propeller transports out of retirement.
The mechanics, however, were unable to get the old propeller engines to produce the rated power. They followed the directions in the manual, and it just didn't deliver. Frustrated, they pulled out of retirement some old mechanics from WW2.
Those old guys never looked at the manual, they just listened to the engines, tinkered with them, and soon got them delivering the power.
There's a lot of specialized expertise that never makes it into any manuals. But I still love the idea that those giant engines were tuned by ear :-) Those mechanics were the real deal.
When I was in Ireland studying my mentor told me a similar story. An old electric engineer was just tinkering his circuit board with his oscilloscope, he's so familiar with signals he can diagnose based on analogue information. My mentor also tried to explain to me (a computing student) what control theory is about. He said if you can send an impulse signal to a system and can tweak with that input, you basically got yourself a system in control theory (might be too naive a version but that's what my memory serves me).
Control/signal processing theory (it's basically the same maths) should be more common on CS courses: it's extremely useful for analysing a wide range of systems. Basically any system which is supposed to be self-regulating can be understood as a control system, and this is extremely relevant in today's distributed auto-scaling cloud systems (as well as important for a lot of DSP).
This reminds me of a story I once heard about shipbuilding during WW2. Supposedly, although designs and blueprints were made in great detail, following them today wouldn't give working ships, because the workers implementing them at the time saw where the designs wouldn't work and fixed them of their own initiative.
In a way, the opposite of today's optimizing compilers.
This happens all the time when you get stuff made. It's generally good and useful, but the real challenge is in getting these changes documented, and getting the changes verified against the original specification. The Hyatt Regency walkway collapse was a good example of this going wrong: while the original design was flawed, the fact that it wasn't easily manufactured meant it then got modified, and even though the builder discussed the changes with the designers, the designers did not check that their original calculations still applied and as a result the structure was substantially weakened and collapsed.
Also, making sure this process for exists and is documented precisely is one of the reasons medical devices are so expensive.
This was part of what got the RAF Nimrod programme eventually cancelled; they were ancient airframes that required an ongoing supply of spare parts, but as you describe building parts from the original plans didn't fit properly.
Yes, each airframe was essentially a completely different aircraft, although each was notionally built from the same plans. Bids for upgrades that were generated against a single reference airframe went massively over budget when executed because no two planes were the same.
The other thing that got the programme cancelled was the crash of Nimrod MR2 Aircraft XV230 in Afghanistan in 2006, as described in exhaustive detail in the Haddon Cave report [0 - pdf]. Part of the cause was design flaws introduced over years of updates, that interacted with each other fatally.
That's also true of WW2 aircraft. Drawings exist for, say, the P-51, but you can't build the airplane from the drawings because the drawings were made after the fact. The real design was the tooling and mechanics.
I think this is also highly relevant to perceptions of the value of higher education within programmer circles.
I can see how CMU's Systems or Theory courses might seem like a complete waste of time outside of the Industry Cluster, where you really don't need to know all that stuff. But I also see the fairly obscene 10x+ difference between the "first job out of undergrad at NoName" programmer salaries and the "first job out of PhD school at MIT" programmer salaries.
That depends on your PhD research area (even if in CS) and country.
In many countries PhDs are only valuable in academia and industrial research institutes, but your salary is capped quite a bit long term.
In Asia a new grad fresh out of college is seen as more employable than a new PhD grad by most companies and salary differences would be minimal. I wouldn't recommend doing a PhD if you're out for a high salary there.
On the other hand in some European countries just having any PhD degree will open up career paths and salaries unavailable to non PhDs regardless of actual skills.
The comment states pretty clearly that fresh PhDs looking for jobs in the humanities enjoy the advantage of "something" over the "nothing" that fresh BAs get. That isn't a difference of 10x -- it's much better.
In the terms of your first comment, the suggestion is that fresh bachelors trying to work in humanities don't get jobs. MIT was not mentioned.
People who major in humanities do get jobs. I know a ton of them--albeit mostly from good schools. And they're not in retail or whatever. There just isn't necessarily the clear career path that there is with, say, a CS degree and the entry salary is probably not nearly as good.
A PhD in English lit or whatever basically only makes sense if you want to teach and that's not a great track these days.
The flip side of this advice is that unless you really don't mind being tied to a single metro center, try to avoid becoming too specialized. Even if you like the city, one problem is that even during industry boom times, rising cost of living is likely to eat most of your career gains.
If you're going to bet your whole career on an unrivaled mastery of the minutiae of Postgres performance, then you better like the Bay Area. If your focus is to be a maestro of credit derivative trading, then I hope you don't mind spending your life in New York.
But general-purpose skills like sales, management, and accounting are likely to be valued almost everywhere. And therefore give you the freedom to live nearly anywhere. It might be scoffed down by the ultra-skilled industry professionals. But a guy who knows how to run an ice cream shop in many senses has a lot more career freedom and stability than a Google engineer or Goldman trader.
On the other hand, mid-tier accounting has a two year part-time ramp-up time for an otherwise experienced professional. From world-class $db expert to... $generic_backend_dev... has, what? a few weeks of figure out how to chameleon to the local interview culture?
> But a guy who knows how to run an ice cream shop in many senses has a lot more career freedom and stability than a Google engineer or Goldman trader.
Yeah, probably a lot of ice cream vendors in the midwest right now who are really glad that they're not Goldman traders!
I cant see your point, I dont know enought about goldman traders but I am certain that a google engineer can get a random senior dev job as easy, if not easier, than a random ice cream shop manager can get another job paying as well as a dev job.
"Don't Call Yourself A Programmer"  is from 2011. "Do call yourself a programmer" from 2013. The world, especially the world of tech has changed a lot in the past decade. A good advice from 2011 is not necessarily a good advice in 2020. Perhaps" programmer sounds like anomalously high-cost peon who types some mumbo-jumbo into some other mumbo-jumbo" was correct at the time, but is no longer true after a decade of software eating the world. Have either of the two authors, or even someone else, written a revisited up-to-date version of this advice?
I prescribe the the fact programmer is the most accurate term for what I do.
Im not an engineer, im far closer to an architect and an analyst. But those things are both from other fields and confuse things.
A programmer needs to be across aspects of engineering, architecture, business analyst, designer, copy editor, ux, accounting, lawer, marketer and even a bit of project management.
That doesnt even begin to cover the domain knowledge often leaking into network admin, sysadmin, operstions, support, and various other functions I get thrown into.
Engineer, in my experience, just doesnt quite cut it.
We are general purpose knowledge workers with the single defining characteristic of continuous learning.
If i had to put a new label on it, id say we are process automaters. But since our focus is on programming computers to achieve this automation and "bring in the automators" makes us sound like robots or bankruptcy auditors, i would say programmer is a pretty clear good fit.
Right but id hazard thats an exception to the rule. How many jobs come to mind that dont label based in their primary function? Because the jobs that do label based on primary function are very easy to come up with.
Software development is a thing, and software developer perfectly fits that view.
I guess I just think* a software developer is a professional whereas a programmer is more apt for things like open source development. Programmer being more of a general term encompassing software developers.
Not calling yourself a programmer when you are one was always bad advice. The "high priced peon" thing was never about the profession, and always about the employer. in the 90s there was a generation of in charge people who really didn't understand the value of systems-thinking, problem solvers who were used to working with huge amounts of change.
> Again, I don't disagree, but rather offer an alternative view, equally internally consistent. I have stayed at one job for more than a decade, in large part because I'm rather attached to the people I work with. To be sure, I got raises, and I was ready to quit over employment terms – but it'd take much more than 10%.
In my experience and talking with friends it is rare that changing jobs only jumps 10%. You are usually looking at a solid 30-50% increase in salary in early-mid career (~10 years). Outside the US, for late career there's a lower ceiling if you only consider local companies.
It still comes down to: Would you rather be seen as someone who creates value (profit), which is a "developer", or who works on odds and ends for the company and ultimately costs money, a "programmer"? Given the two options I think the most advantageous option is obvious.
I will admit however that my view on this is rather arbitrary. I don't think we really have a good way to resolve what's best.
I could actually see myself botching fizzbuzz if I had been given it during the first 10 years of my career.
Up until that point it had never occurred to me that someone might apply for a programming job who could not write the simplest programs. Thus it would never have occurred to me that someone asking me such a simple question just wanted to see the obvious simple answer.
I'd have assumed they wanted me to use as much of the language as I could. So if they asked me to do it in Python, for example, I'd have tried for something like this:
def fizzbuzz(n, *args):
cur = ['' for x in range(1,n+1)]
for m, postfix in args:
cur = [y+postfix if x%m==0 else y for x, y in zip(range(1,n+1), cur)]
cur = [str(x) if y == '' else y for x, y in zip(range(1,n+1), cur)]
print("\n".join(fizzbuzz(100, (3, 'fizz'), (5, 'buzz'))))
...and since Python is not one of my main languages there is a good chance I'd botch it.
Honestly, I'd probably fail it because I wouldn't believe they'd ask me something so trivial.
I'd question the heck out of it looking for tricks. Then I'd probably think "no they want something complicated. It can't be that"
I'd probably totally fail it. I've been writing code every day for over 25 years but if you asked me that in an interview, I'd totally completely utterly fuck it up.
I'd walk out and the interviewer would think me profoundly incompetent. Then I'd go home and have a terrible day thinking "wtf was that? All he wanted was that. You could write that when you were 7 on an apple 2, wtf were you doing?"
So now I'm just enjoying my time contributing to open source. Whatever.
It's a great time to not work, unemployment is lucrative.
I got asked it one time and did it fine. Then they asked me to do it without a modulo operator. I had a mental block as it is so easy and obvious to do it with a modulo operator that it was kind of difficult to think about doing it another way.
Likewise I got asked about python with 2 list comprehensions. Then I got asked to do the same thing without an intermediate variable. Basically they wanted a nested list comprehension. This was not a difficult task, but not something that I ever do, as I find nested list comprehensions terrible for readability - I always use an intermediate variable. It would be easy to mess this up under the stress of an interview.
Those things frustrate me in interviews, I can think of 4 ways to immediately do it but I know for a fact they only have 1 way written down and it's my job to guess it. If I say "you can make a field" and they have zero knowledge of number theory well my chances go right out the window.
To them I obviously have a "wrong" answer. They ask you to be clever but only in some proscribed secret way that they have no intention of disclosing. Nonsense.
If instead I respectfully show them the multiple ways, it's still naturally "combative" because there's no other way to reliably answer the question.
They're just asking for experience to fail. They're looking for something who coached themselves, not someone who actually knows anything.
No wonder silicon valley is awash in cargo cult driven shit software. Look at the process.
Yet again an interview process that selects for dimwits.
Might as well guess what number they're thinking of
That's only because the interview process is being run by people who don't know what they're doing. They may be able to code, but they're amateurs at interviewing.
You could do the exact same thing, but with sanity. When you ask what they do without the modulo operator, you're looking to see if they just have a cookbook method memorized, or if they can handle having to adapt it. You don't have a "right" answer - if their answer works, it works. If it's kludgy, that might be a bit of a mark against them, but less so if they know that what they did is kludgy. And so on.
It's not all like what you describe. There are people who can actually interview.
Whenever I've seen it used or had to use a fizzbuzz-type question as an interviewer, it has always been stated that it's a warm-up question for which a straightforward implementation is fine. People who are senior get a harder warm-up question but the same reassurance is given.
If someone tossed me a 6502 assembly book (in case the candidate didn't know it) and a simulator and told me to implement fizzbuzz in that and create some test script, now we're talking. You never work with 6502? Even better! That's every new job: a bunch of new stuff.
We leave the amorphous world where there's giant stratas of assessments and opinions and have a concrete problem
I don't know about "most", but I phone-screened four candidates last week, all claiming to be currently employed (with 3-10 years industry experience).
Two of the four couldn't finish fizzbuzz (in the language of their choice) in 30 minutes. It feels a bit unethical to name their employers, but they were companies that would be familiar anyone who reads HN.
When I worked for FAANG, IIRC, the ratio was about the same, so I don't think it's a problem of recruiting.
In a phone interview? When they could just fire up Google on their laptop and get an answer in 30 seconds, and you wouldn't know unless you heard them typing? I mean, I guess you could conclude that they are too honest to cheat, which is a plus...
While that is a real problem, and I completely flunked my whiteboard coding test for my current job (they liked me anyway, appparently!) I have observed "senior software developers" who fail at FizzBuzz even when they can write it in their home, on their own time, in their own editor, using their preferred language.
These are people who likely happened to be "lucky" and rose through to management/team lead positions before they had time to truly learn the details of programming, and then they spent years dealing at higher levels of abstraction and their foundational knowledge atrophied.
The number of expert beginners in our field might surprise you.
I've seen plenty of bad FizzBuzzers, but in general they are not very good at the higher levels of abstraction either. In my experience, they can talk the talk, and make sure the have a new job before the shit hits the fan. Which at that level might take 2-5 years, the timeframe for a major new application to completely develop.
Yes. I deliberately avoided saying anything about how well they handle these higher levels of abstraction. ;)
I believe knowing the fundamentals is critical for being able to reason well about the higher levels of abstraction. As Alan Perlis put it back in 1968:
> In a situation where code actually has to be produced, nobody should be allowed in the system who doesn’t write some given number of lines of code per month. I think that one of the major problems with the very large programming projects has been the lack of competence in programming which one observes as soon as one goes above the very bottom level.
He goes on to propose a scheme were people at all levels in the development effort get some time to get their hands dirty on a rotating schedule. That sounds very sensible, in my opinion.
Respectfully, I don't think the existence of leetcode could be exposed to all possible developers and fix the underlying issue. Certain education and self education pipelines focus solely on the actual work being done in real world applications, and raw logic chops are honestly not required for much of that.
It's no surprise to me a team could make an application and then fail at FizzBuzz. Not saying that's a good thing, just that I am not surprised people can make it so far without being able to do simple logic programming.
My old job was a bit like that, I spent most of my time just creating new models and building API endpoints, or finding gems/packages/AWS services that did what we wanted to do (it did make for a nice looking resume though, with a laundry list of AWS skills). In the two years I worked there, there were only a handful of times I had to write any code that was more complex than fizzbuzz. It was an interesting product, but you could've taught a smart 17 year old kid how to do everything I did.
I'm happy that these days I'm working at a much more mentally stimulating job. I regularly have to use what I learned from my compsci degree (especially operating systems and networking), and solve complex problems that require me to actually think. It's the kind of work that validates why I went to university.
I tend to do much of the phone/person screening at our shop. I'm surprised how many folks try to bluff their way in. You ask a big-O on maps, lists, and the different implementations they will rattle off the (correct) stackoverflow response immediately. Hit them with basic questions, like handling an exception or closing a resource/JDBC connection... and can just get blank stares.
Codility and Leetcode... screen that folks can code, but the folks who tend to be good at a quick grind don't always produce good code. Not a huge fan of it. I don't even look at the report anymore.
Angular webpack frontend dev is probably the only job fizzbuzz is relevant to, don't expect any other job that makes anything useful to do fizzbuzz, because usefulness and fizzbuzz are mutually exclusive. And what is even leetcode?
Very pleased, but also confused, to read two quite good and quite different articles on the same topic in a row that both coherently referenced Marxism.
FWIW I work at a not-originally-software-native company that is pushing in a more software-first-oriented direction, as much of the world has since 2011, and that undermines the title "don't call yourself a programmer" more than anything, but also some of the other points in the 2011 article. I do think much of the cynical stuff in the 2011 article is very important for naive tech enthusiasts and naive young professionals to understand, and it seems full of good advice, but the linked 2013 article is also a good counterbalance.
I call myself a computer programmer, because I program computers for a living. Yes that's not the only thing I do at my job, but the other stuff is in service of the programming. Patio11 is a fine writer but he got a little too 3-dimensional chess on this one. You can just say programmer, it's fine.