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.
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.
In a way, the opposite of today's optimizing compilers.
Also, making sure this process for exists and is documented precisely is one of the reasons medical devices are so expensive.
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.
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.
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.
You will not easily be reaching upper management without a PhD.
I can’t think of any C levels or one level below that aren’t credentialed as such.
I know as I started work at the worlds leading Research association for hydrodynamics and left for the commercial world as the pay was so bad.
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.
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.
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.
> 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!
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.
It takes programming, and all the things you mentioned, to develop software.
On top of that it is not an overloaded term with some other title from some other industry.
I like software developer. Its probably the most commonly understood term too.
Odd fact, accountants sometimes hire interns called "coders" because they code account transactions.
Its one of the most tedious jobs I've ever had.
I mean I'd image that attending meetings takes up a huge amount of time for a CEO. But they aren't called "meeters" because that's not all they do.
Brick layers, plumbers, painters, miners, accountants, lawyers, sailors, banker tellers.
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.
*Nuanced and subjective thoughts.
Ha! My faculty is called 'Authomatics' even though they teach programming and computer science. During my career I have automated things, though. It was a good name.
There are more dont's than do's: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
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.
I want GTD, working product with real users. I like solving use cases with product owner, balancing technical debt, the patchwork of system administration, use of libraries and writing code.
I've thought about myself as programmer until entering freelance. It appeared the act of programming computer is not valued. No need for clever code, make it simple, iterate.
McKenzie was at least somewhat correct. Very rarely do you end up in a place where you have time to create something you are truly proud of.
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.
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'))))
Most good developers are already employed, so there's this constant pool of unemployed programmers (the 1% who can't do fizzbuzz) applying for all the jobs they can.
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.
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
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.
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
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.
Re typing: You can usually hear it unless the mic is muted (part of the reason I try to keep the conversation going).
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 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.
Why write fizzbuzz yourself when you can just import it? https://www.npmjs.com/package/fizzbuzzify
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.
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.
Before, you'd need a skilled programmer to take 3 months to link together applications or data from different companies, and your accountant can do it in an afternoon using a graphical interface.
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.