I've been programming for a long, long time. Went to college for it when I was a pre-teen. The more and more I code the more I see it closer to something like music than something like engineering. Getting a little garage band together isn't hard. A couple years of practice and you and your friends can play at a little bar or at least at a high school shindig.
The same is more or less true for programming. A simple stack of JS, HTML, and CSS is pretty easy to get going. And if you're content to make marketing sites for advertising companies or similar, then go nuts. That's your simple jam and you rock out on it as much as you like.
Other people want to learn violin or weird keys or timings or cross rhythm. They want to woodshed some African drums and mix them into complex arrangements. And you know what? It is harder than playing a simple guitar for a simple song.
We have the same thing with software, and once you've put in the years you find a sort of series of specializations that make you stand out a bit more and get you a bit more money.
So when people say "programming is easy" what they really mean is that it's easier than most people expect it will be for the financial incentives it provides. Compared to, say, structural engineering which takes four years of focussed study then a long period of practical understudy, software is easy and it pays more. Almost any structural engineer can become a data analyst or junior data scientist and make around double the salary within a year or two.
Yes we've all had the frustrating semicolon days, but there are highlights too. Fast feedback, ease of learning new technologies, ease of scaling to millions of customers. There are many advantages and I think they make up for it.
"I've been programming for a long, long time. Went to college for it when I was a pre-teen."
Yet you don't tell us how old you are, so it's hard to get a grasp for how long you've been programming. As someone who first started programming in 1979, I notice that there are plenty of people who say they've "been programming a long time" who weren't even born when I started programming. This isn't a criticism, just a comment that we don't really have any idea how long you've been programming. I can picture a 29-year old saying the same thing you did. Time is relative, something that becomes more and more clear, I think, the older a person gets.
> As someone who first started programming in 1979
I absolutely love that there are seasoned experts like you on HN.
Would you mind sharing with us what you're working on these days?
Compared to you I'm relatively young (I've been programming around 26 years) and in my circles I don't get to mix with too many older programmers.
Would love to hear your thoughts on career trajectories.
For me personally, I'm gradually spending less time on pursuing commercial interests, and more time on pro bono projects - and I love the idea of working on open source software indefinitely once I retire.
Same here, 31 years. I'm 43 and started in around 1989-1990 at age 12. I didn't know anyone who had ever even attempted to program a computer, so I was completely on my own. I have a good grasp now but remain humbled by the craft (coding every day). Nearly everyone I know now is either where I was twenty years ago or insanely elitist.
Still on my own.
Another relatively young programmer here: born in 80 started but started programming somewhere between 92 and 94 on Commodore 64.
I've been extremely lucky to mostly have worked with mostly ordinary programmers with some extremely good[1] thrown in and luckily even with the brilliant ones all except two of them were also down to earth and nice as well.
[1]: "master of all trades", all-knowing teacher types with "saintly" patience, learns-anything-in-two-hours-and-proceeds-to-fix-hard-bugs-after-lunch
I am 52, I started in BASIC programming in 1979. I am currently disabled and unable to work. I am trying to get better so I can become healthier and get back to work.
Programming became a lot easier when Visual BASIC and Delphi came out. Just drag and drop controls.
Due to ageism I am sure I don't fit the culture of a startup or relate to 20 somethings. They hire them young anyway not old. So I do tech support for family and friends to get by.
And can slightly change how one does and says things, which others can notice, -- to some small extent, can become a self fulfilling prophecy.
(And this can work on in a good way too -- if you say to yourself maybe: I like these people, I like most people, what matters is not age, but if the others are curious and want to learn new things)
Now, of course I do believe that ageism is a thing, still, I'd think there're somewhat many good workplaces that aren't much affected by it
While there is a degree of ageism in the industry - avoid companies that advertise their ethos as "work hard and play hard" because having to do most of your office politics half-drunk in the bars after work is not much fun - there are also a lot of people in the industry who genuinely care more about a person's ability to learn and adapt than the date on a birth certificate. Believe in your abilities. Wishing you good health for the future!
Thank you, I learned 27 different languages since 1979, most are so old that there are no jobs for them anymore. I used to be a master at Visual BASIC until Dotnet came out.
I can learn any language on the market if I wanted to. I am a quick learner as I have the theories of computer science in my head as I learn.
My first "paid" gig was winning £50 for submitting a game written in AMOS Basic to an Amiga computer magazine, which got picked as the magazine's "Game of the month". It's still an achievement I'm really proud about.
I’m 53 and started FORTRAN programming in 1975ish on the VAX at my moms work. Bought an Ohio Scientific C2-8P a year or two later with my brother, and that’s when I got into programming games and really started to learn (BASIC) fast foreword 44 years or so, and I’m working in solidity writing contract code in a blockchain startup with a bunch of early 20s guys. They call me dad and are always asking advice on architecture and data structure problems Just closed our first round.
Wow, that's an even longer time. I started tinkering with code in the late 80s when I got my first computer at 4, then went to college when I was 11. First job at 14. I feel like 30 years of coding is long enough to feel like a long, long time. My pops had punchcards at home from the good ol' days.
I wasn't part of the couple waves of programmers, but I think it is fair to say I was in pretty early. Retying out programs from magazines isn't even something most programmers have considered these days, let alone programming without the internet.
But the essence of your comment is right. Of course there would be people out there that have programmed for twice as long as I have. That's a little frightening to think of.
> Retyping out programs from magazines isn't even something most programmers have considered these days
Oof, this takes me back to the day I learned about RAM the hard way. I was typing out a program from a magazine. It seemed like it took forever, even then. About halfway through the computer rudely informed me that 4K of RAM is not, in fact, enough for everyone.
Ha. Soviet magazines were more considering. They listed memory requirements well in advance, when I was learning racing games for my programmable calculator in late 1980s.
I learned originally on a VIC-20 by typing in games out of books from the public library. At some point we upgraded to an XT and a friend sold me a copy of Power C for $20. It came with a beautiful hard copy library reference and the rest, as they say, is history!
Power C! I grew up in Germany and after the inevitable BASIC, C was the second language I learned, using Power C as a compiler, which I ordered by mail and which arrived from the States several weeks later, including the hard copy reference manual you mention. I also remember it came with a rudimentary graphics library I used to create screen savers for friends. Good times.
Still costs the same now as it did when I bought it!
Yeah, the graphics library was great! When I moved on to Linux and gcc, I was disappointed for a while that I didn't have all those super simple primitives to work with.
> Retyping out programs from magazines isn't even something most programmers have considered these days
I'm still retyping stuff from stack overflow instead of copying. I find it really effective to really think through the code you're borrowing from somewhere — because once it's committed under your name, you're the one responsible for it.
The last thing I think I got from SO was an implementation of the Boyer-Moore Algorithm for a byte searcher. I think retyping it would have probably introduced bugs: and as it worked on a test case I had to hand and could verify (finding the data header size in a WAV file by looking for `data` followed by the SubChunk2Size bits, which I could verify with `afinfo`) I was happy to use it rather than learn how the algorithm worked.
As Morpheus said, “Time is always against us”.. so I just made sure it followed our coding standards, checked the test cases, and moved on.
But, I am old enough to remember code listings in magazines. I like to think the typesetters introduced deliberate mistakes because they hated the work so much - not to disrespect the fine profession of typesetters, but when you set your 100th `Poke` command in a row, you might think this isn’t what you signed up for..
> I'm still retyping stuff from stack overflow instead of copying. I find it really effective to really think through the code you're borrowing from somewhere
Numerical Recipes in C. Had the hard copy but not the disk.
Often the code was just to obscure to work out as you typed, but there was some real value to typing it in. You got some real feel for it. Additionally it offered hard lessons in writing test cases.
Please don't call me that. I really believe any 11 year old could learn what I did with parents like mine.
When I compare the skill involved with something like violin versus the skill that's needed to validate HTML forms with JavaScript or creating an application in Visual Basic, I really do not believe that people that happened to study software at a young age happen to be geniuses just because they did. Yes I'm smart, but I really believe that this path could be open to anyone that age if they have the interest and I think the internet has unlocked many people that have learned the same skills without the credentials.
I used to have this mindset, but then I had a small stroke and lost significant IQ points. I slowly, but never fully, gained them back over two years. I realized that the ease that I saw/see solutions, compared to others, wasn't just related to the time I put into thinking about them. Much of it came for free, in what I can describe as the length and number of the tendrils reaching out to explore whatever "problem space".
I no longer believe that "anyone with an interest" can be at the same level as someone that can just see the answers, with little effort. Some people have fewer/shorter tendrils.
This has definitely changed the way I interact with people. I used to get frustrated when people, who I thought should be able to understand, couldn't. Now I realize that they just can't as easily. They need that picture drawn out for them, and even then, they'll never see the nuances or perceive the textures of the problem, unless you point it out to them.
I think I'm lucky for being born with the mind that I have. It has made my life easy, pulling me out of poverty, with a mostly addictive enjoyment in what I do. I think you're probably luckier than you realize.
The way I talk about this is to frame what people call intelligence as the combination of memory (+ actual memories) and comprehension.
Your ability to 'just see the answers', in this framing, stems from having a lot of data points readily available and the ability to combine them together quickly.
There are definitely people who are better at remembering things, and piecing multiple ideas together quickly, but these are also skills that can be trained. I think it's likely that a lot of 'intelligent' people are simply people who actively (though usually not consciously) train these skills because they enjoy them.
In the same way that many fit people don't have to think about exercising - they do it because they enjoy it or without any particular goal - there are people who see an interesting problem and immediately start thinking about how they might solve it or how it's similar to other problems they've seen.
In the same way that anyone can implement a training regime to improve their fitness I think anyone can implement a training regime to improve the number of data points available to them (read lots!) and their ability to combine that information together (solve puzzles, especially theoretical/not personally applicable ones like "how would I get that boat free?").
You find it odd that people think about what intelligence is, or how it presents?
If you’ve got links/references/keywords for research that invalidates (or validates!) these ideas please share them, I’d love to look them up. From what I’ve read the idea “intelligence can be (at least in part) described as having knowledge and being able to apply that knowledge to new problems” is a well trodden one.
I haven’t seen much on the idea that some people may be predisposed to engaging with stimulating situations, so anything you have on that topic would be highly appreciated. I have seen writings on how a stimulating environment is important, and on how encouraging engagement can be effective (for example asking questions of children and allowing them to answer, vs answering for them).
[edit]
In my original post I should probably have written “is to frame a lot of what people call intelligence as” - I definitely don’t think this is all intelligence but I do think it has a significant role in what the gp was talking about, this ability to see answers quickly.
> [edit] In my original post I should probably have written “is to frame a lot of what people call intelligence as” ...
Ok then i understand better what you mean.
Actually there's a word for that type of intelligence:
Crystallized intelligence.
And I had another type of intelligence in mind:
Fluid intelligence.
I think we spoke past each other (or I spoke past you) thinking about different things.
Anyway, one of those, one can improve eg by reading, getting life experience. But the other one, is fixed (from what I've read) once one is grown up.
If you want to, you could websearch for those words. And also, wikipedia has a section about intelligence and inheritance (hint: life is unfair).
> I have seen writings on how a stimulating environment is important, and on how encouraging engagement can be effective (for example asking questions of children and allowing them to answer, vs answering for them).
That sounds great :-)
From what I've read, those things do work (!), when one is a kid / young. And from what I've read, it also prevents the brain from deteriorating, when one is old (using one's brain reduces the risk for dementia).
> everyone seemed to think I was smarter than I believed I was. I feared I might fail miserably and finally prove how wrong they were about me
I can totally relate to that. Once everybody told you you're a genius, the pressure not to fail is incredible.
I started programming at 8. I got next to no help from my parents or my teachers, until the time I entered college, and by that point I felt I knew as much as the professors, sometimes more. I always avoided talking about programming, since that would get a me more genius calls on top of what my grades got me. And it doesn't help with making friends. Over the years I had maybe one or two friends who knew about it. Few would've believe me if I had told them what I could do.
I feel like there's nothing special about the path I took. I feel like anyone would be able to achieve the same knowledge I did given enough work and support. I must have spent thousands of hours programming in my teens. What nobody seem to realize is that the genius label is wrong, what they really should have told me was that I was "passionate". Anyone who is passionate enough can become a master.
> I must have spent thousands of hours programming in my teens.
That's what I think about when I hear people complaining about gatekeeping in our field. The books are open, the courses are there, interesting and useful applications abound. Given the same level of effort I think much of the difference between social groups would vanish.
I don't know what the university courses entailed. I'm basing "genius" on my knowledge of the current Computer Science curriculum. If you were doing CS courses at age 11 I do think you must have genius level intelligence.
If it was more practically-orientated, then I agree with you :).
I'm not really sure what to work on next. I was focussed on arms control for cyberweapons for a while, and I made some real progress, but I want to work on something new now. Maybe finding a way to scale up good things like trust or good will? I want to find something where I'm making the world a better place but also working on something that makes me smile. Trying to fight weapon dispersion is exhausting and discouraging and, ultimately, as I learned, futile.
> Maybe finding a way to scale up good things like trust or good will? I want to find something where I'm making the world a better place but also working on something that makes me smile.
Have you made any progress finding something new to work on?
Maybe I'm projecting here, but I'd imagine this is the dream of most of HN, no? But I don't know which is harder: finding such a unicorn idea, or executing on it once you've found it.
> Maybe finding a way to scale up good things like trust or good will?
Have you considered working in the cryptocurrency space next? I think that would satisfy your desire to find ways to scale up trust. One of the key value propositions of crypto is building trust at scale on the pillars decentralization, cryptography, game theory, and economics.
> Retying out programs from magazines isn't even something most programmers have considered these days, let alone programming without the internet.
Wow. Flashback. I started programming late age wise (college freshman in the 90s), because until that first student loan we didn’t have enough money to buy a computer. I would go to the local bookstore and copy code out of the programming magazines and books. I remember writing some c++ code, bumping into a problem I couldn’t solve and driving to the bookstore to look at the books for a solution.
Going to college for programming must mean they are quite young indeed. When did colleges even start offering programming degrees? Unless maybe this is some sort of vocational college.
Depending on what is meant by 'programming,' computer science really grew out of mathematics and occasionally physics departments at colleges in the late 50s and early 60s. Disciplines started establishing CS departments in the US around the mid- to late- 60s. I'd say anyone exposed to that period on could be considered as having formal training in "programming" in a college or university environment.
I have a good friend that worked during the 60s era programming with punch cards doing applied physics work in FORTRAN (pre 77) which was already pretty big by then. You could probably go back a bit further but I don't think much was being actively taught as a sort of course one might expect today then. So I'd say you could have at most 65ish years of programming since formal use in college.
No, it was not software engineering at the time per se but I'd absolutely call it programming.
Electrical Engineering departments were also starting to offer more and more "programming and computer" related courses as well. At a lot of universities these eventually branched out to become Computer or Software Engineering programs.
My uncle worked at the National Institutes of Health for about 35 years doing bioinformatics and protein structure modeling. In FORTRAN. Always in FORTRAN. He knew other stuff, but the bulk of his work was always FORTRAN.
I didn't learn fortran in university, but I did have to learn it for a job. It's still THE language for scientific computing. So in any job in or adjacent to scientific computing, you're bound to run into fortran.
My mom taught programming at the college level in the early 80s, in a computer science department at a state university. At that time, the big universities had computer science departments. The 4 year colleges were more of a hodgepodge, ranging from full blown CS, to a handful of programming courses offered by the math department. By the time I graduated in the mid 80s, CS departments were pretty widespread.
Someone who entered college at the start of the dot-com bubble is in their mid 40s, and that's not even when CS degrees were first offered, just when they started entering the public consciousness.
You could easily have a CS degree and be past normal retirement age.
CS College degrees in dot com era were hit and miss. Also often had a weird mix of electrical engineering courses thrown in.
Was quite common to do 2-3 years then drop out and start a job. So much so that people with degrees were often looked down on. Exceptions for things like MIT.
After year 3, there was nothing left for me to take. So I took a job.
I would like to have a degree, but it was the right call at the time.
Few years ago I went back and started an Art degree. Was a blast.
I'm still holding onto some of my mom's CompSci homework from the early 80s or so. Mostly based on flow diagrams and what amounts to state machines. Sadly no punch cards, though she talked about taking them in to run assignments.
Story goes that she had a campus job cleaning, and made good friends with the guys in charge of running the mainframe by bringing them food and drinks when she stopped by. Which of course meant she could often get them to sneak her stack of cards into the queue overnight.
Details are fuzzy since I last heard the tales over a decade ago, and haven't dug the assignments out in forever.
NC State was celebrating 40 years of CS in 2006 or so and they weren't the first. CS degrees have been around since the 1960s, so 50+ years at this point of CS as a separate degree program in the US. Apparently Cambridge offered their first CS degree in 1953.
Yes, but they took quite some time to spread to the whole country and to every major university. That didn't really start until the 70s and 80s (in line with when NC State got established).
I switched my major from 'business' (yawn) to comp sci 35 years ago (1986).. at my school, it was previously a 'concentration' in the Math department, which meant you got a BS in Math, concentration in Computer Science. It wasn't a full Bachelors of Science degree until about two years before I got there.
I think you are kidding. Even my southern noname university had cs degrees 40 years ago. We had 3, one that was computer engineering, one in arts & sciences, one in the biz college
Started on a pdp-8/E in 1973 with its staggering 4k of 12-bit memory. "Going to college to program" might have meant going to where the machines were as most of them were on the large size... We had to descend on the college computer centre, which drove the adults nuts. Rugrats running about, fixing their programs for them. Times were different then, but the graduate-to-hacker test was to start with blank paper and end up with a working program. It was too big and too slow, but at the end the new hacker was enlightened.
They probably meant they went to college for something like computer science or computer engineering that includes a ton of classes that involve a lot of programming?
Or, since he says "pre-teen", it could just be that his parents sent him to a programming class at a local community college when he was twelve years old. That's the sense I get, actually. The number of people who start actual college as a pre-teen is vanishingly small.
We had a Pascal class on a VAX in my high school in 1983, and it was fantastic. We used the classic "Oh! Pascal!" text and it was great preparation for college. There was no CS major at the liberal arts school where I ended up, but there were courses with Turbo Pascal taught by the math department before I graduated.
I first programmed a calculator (well, copy-keyed a hangman game program into a calculator) back in 1980. Passed my 'O' level computing exam in 1983. Started building websites in the last years of the 20th century. Looking back, none of that feels like "programming" to me. I finally started programming when I had a mind-blowing "A-HA!" moment about what Object Oriented programming was all about in 2009 - which made a change from the many, many "wtf" moments I had with non-Basic-like languages before then.
Also not directed towards you, but just because someone has programmed for a long time doesn't been they're particularly good at it. Plenty of people don't learn - it's not even a character flaw, some people just program for the job.
I don't disagree but the idea of equating software development with some sort of artistry also allows the existence of the 10x programmer as, you know, a more gifted artists. Whether any one of us believes in 10x'ers aside, there are a lot of problems with this from the perspective of those paying the salaries, not least of which it means developers are not simply interchangeable cogs in a machine/process.
The most horrendous application I ever worked on was a java servlet app where the original developers didn't understand thread safety. They didn't let that stop them though. Every collection was a synchronized list or concurrent hash map, every access was wrapped in a mutex or synchronized{} block. It was really really bad; lots of race conditions and deadlocks, lots of production outages and a lot of "add more locks". In the neighborhood of 200,000 lines of this. It was "artistry" of a sort.
That application got the company to IPO, so the business owners were overjoyed with it. What's the point? Gatekeepers can gatekeep, artists can create art, but even the most banal garbage can make someone a lot of money.
I've been consistently amazed at how far companies can get on shoddy code.
In my experience, even majorly successful startups that turn into companies worth 10's of billions tend to have lots of technical debt.
Honestly, I believe that at some scale its very difficult to get the caliber of experience and talent that can keep a codebase clean.
People often say accruing technical debt is a form of shortcutting to a more business focused goal, but in my experience the technical debt is almost always created by accident through lack of experience rather than a conscious tradeoff. Especially when you consider a SaaS company where your product lives forever and is meant to scale, taking on technical debt for short term gain is almost never the right decision.
Not to reopen the 10x engineer debate, but I've observed that the top 20% of engineers tend to do 80% of the total work of an org. Of course, 10x is relative... But there are definitely individuals that are 10x more productive than the median engineer. And for whatever reason, that seems more to do with an individual's personality and drive than their level of experience... Though of course experience helps.
Especially as a project scales, somebody who makes good technical decisions will only increase the productivity margin between themselves and others. What I see in a lot of these SaaS codebases is that it takes a week to do something that should take 1 day, due to amount of technical debt and spaghetti code.
Software is still a new industry. I fully believe the companies that win in the long run will be the ones that have the best codebases (assuming software is what differentiates your business). The impact that it has on velocity is just monumental.
Code quality and philosophy of well written code is not stressed at all in school... One example of how far off we are from maturity as a discipline. There is a whole school of thought that's currently neglected that will become mainstream in the future IMO. Similar to other engineering disciplines...
> Especially as a project scales, somebody who makes good technical decisions will only increase the productivity margin between themselves and others.
I once saw a customer obsessed junior engineer push out features that our users really wanted, but that none of the senior engineers had time for.
Half a year or so later one of the senior engineers was complaining that he had to rewrite everything that junior engineer did due to how poorly the code was written.
End of the day? The junior engineer's code is what got shipped and made the user's happy. Was it tech debt that had to be rewritten? Sure. Was my team happy with him for being willing to work with us to make the product better? Yup.
Perfect is the enemy of the good and all that.
(I've also seen code where changes took a long time because someone invented a DI framework and layers of XML configuration files when a single if statement with 2 branches would've done the trick. Was the solution well engineered? Yes! Very reliable, good quality code. Took me a few days to get ahold of it and add that 2nd conditional...)
Sure, but if a senior engineer had written it in the first place, it wouldn't have had to be rewritten, thus saving lots of time (assuming senior engineer is strong technically :))
If you had instead hired an additional senior guy who was paid 1.5x compared to the junior guy, it would have been a better outcome for the business all around. Of course just using this contrived example, and the exact salary numbers change the outcome...
I value code well written, maintainable, and testable but sometimes I'm a bit put off on certain conclusions. Once I read a report by a guy who had come in into a business to re-work an, by his words, unmaintainable mess. This had been written over five years by a single guy and no-one seemed to be able to make sense of it.
The one re-writing touted what they had accomplish, a full re-write with a team of 15 or so people, in a couple months. I can believe that some guys are dickheads and do crap and are anti-social or don't want anyone touching their stuff and think they're the last cookie in the packet.
On the other hand, there's a real difference between writing from scratch something, with features tacked on week-in week-out, contradicting requests, no time to work through issues or problems, being the only one allocated to the problem and having no real plan or feature map laid out, during 5 years and then coming in, when all the system is laid out, all the bugs and domain knowledge have been made visible, there's a working system that can be used as base to understand the objectives, the rough edges, problems and pain points are also known, and rewriting it from scratch better.
Lastly, it's also not known if they had been the ones writing from start with the same constraints if it would have been so pristine as they claim, and it hasn't stood the time for 5 years yet. Maybe it'll end problematic as well but now it took a team of 15 or so that probably cost more than that single guy for 5 years - and still made something that helped keep the business throughout.
Part of the problem is that "well written code" is unbelievably subjective. Take 10 people from hacker news and you will get 10 likely very different answers, some of them most likely the exact opposites.
Maybe it has to do with being "a new industry", but by now we have accumulated decades. I think it's more because you can get away with it. In other industries, you can't. If a bridge collapses, people die. If a car's brakes fail, people die. If you administer the wrong amount of anesthesia, people die. If you write spaghetti code .. shrug and move on.
Even within the code base of the place I work in, a few hundred sw engs in total, we don't have a shared understanding of what exactly "good", "clean", ... design is. Everybody has an idea, and there are overlaps, but the criteria that people seem to optimize for, and thus the conclusions they draw about design, differ vastly. Within my company, and even more so across our industry.
> Part of the problem is that "well written code" is unbelievably subjective.
I'd recommend you check out Code Complete if you haven't read it. It is an excellent intro into best practices although its about 1000 pages and a bit dated. As it turns out, we as an industry do have an understanding of what makes code better, and it turns out, its mostly not very controversial - push complexity as low as it can go, simpler interfaces tend to be better, argument pass through causes errors, functions longer than 80 lines are associated with higher error counts, optimize code for human comprehension later (~70% of the effort that goes into code is maintaining it) etc etc.
What I personally check out does not matter much. My point was a lack of consensus within the industry. It does not help if I read the same book as you and we two agree 100% what exactly we mean, when the next guy considers most of that nonsense. And that's what I observe with colleagues.
> it turns out, its mostly not very controversial
I don't believe this until proven otherwise with actual data. Any programming concept on this planet eventually gets an article on the HN front page that argues for why that particular concept is really bad and then we are having a huge discussion about it.
> I don't believe this until proven otherwise with actual data.
I don't remember the last time that a piece by Uncle Bob or Martin Fowler—and they're just two examples, I've seen quite a few more who are generally met with agreement every time they're posted—was heavily criticized or disagreed with here.
And when I do see disagreements, they tend to come from people who don't seem to have nearly as much experience as those guys do or who might have misinterpreted their point (much like how the idea of agile has turned into something that only reflects the manifesto tangentially, and accidentally at that) and who are, perhaps not coincidentally, likely to fall in the "programming is easy" camp.
And even then, "controversial in hacker news" is hardly representative of what's controversial in the field at large (which I also understand goes against my own first point).
If anything, Code Complete was for me further evidence of its subjectivity. I'd have to pull the book out again to find examples, but I remember finding a good 20-30% of the "better" examples actually more difficult to read, or there being a third way of doing it not mentioned in the book.
Heh, good code is the kind you can throw away once you’ve used it to sell stakeholders on an idea. It’s contextual. Or, to put it another way: is a very structurally sound bridge located on a road that no one uses considered a “good” bridge?
I'd raise a difference between good and useful then. That is still a good bridge, but it's not a useful one. I think that also transfers to programming. That also raises that what makes a bridge good is not usefulness it's perhaps structural quality. Maybe the only thing that makes programming good is usefulness in which case my point is moot.
There's subjectivity, but you can also certainly make objective arguments for why one form is readable relative to others.
For example, here are some principles I can strongly justify:
Bubble important info. Structure your code visually such that signal to noise ratio is highest. E.g. appropriately named variables should be more immediately visible than implementation details. E.g. if variable is named well, you can typically ignore the RHS of an assignment... It's an implementation detail. Don't indent such that RHS of assignment is emphasized. We can debate that point, but I'm using objective reasoning for defining why this style is beneficial.
Human readable naming. Name of variables should define exactly what they represent and nothing else. Your code should be written to read as closely to natural language as possible. E.g. if in a functional language, and all functions describe what they do exactly, RHS of assignments are indented to deemphasize them, you can understand high level of any function quickly by scanning LHS assignments and top level expressions. The more unclear your names, the more "mental recalls or lookups" the reader has to do.
Don't use anonymous functions. For anything longer than one line, always used a named function that appropriately represents what it does. Reader should not ever get implementation details pushed into their face. Pushing implementation details to the forefront is the biggest readability error I see in code. It's almost never important for business oriented code unless there's a bug in it. Majority of the time the reader is simply trying to get context and understand meaning of the code. Optimize for this.
Hide your declared functions out of sight. Reader will get high level understanding of their use where called, due to their name. If they want to reference the implementation, they can go to function declaration, but typically they won't need to. Don't declare functions sibling to your core logic. They should not break high level flow of function (does not help readability). Frustrating when people declare functions above where the core logic of the function is... See it a lot in python due to lack of inner function hoisting. Books have footnotes for a reason
Hide implementation details as much as possible behind api boundaries.
Model component apis such that implementation details are not exposed to caller or creator. Don't mix naming of business concepts and render logic. E.g. if you have a generic graph component, nothing within that component should reference your business domain. I see this mistake a lot. More generally, never name something which implies an understanding of a different context than the one you're in. By doing so you're coupling the two domains and increasing the amount of context the reader needs to understand your code.
Prefer immutable variables. The more constants and immutable state you use, the fewer things you have to track in your head as you follow code. You know once you see an assignment, that variable will never change. You don't need to scan every line between assignment and later use to determine whether that var is later modified.
Don't nest expressions too deeply, such that it's difficult to parse. If you can instead assign to appropriately named variable, reader can typically ignore the expression altogether.
Prefer named function or variable that describe the result of a computation rather than inlining an expression. If featureFlag == 1 represents isFeatureEnabled, assign that to an appropriately named variable. Anytime you make the reader "infer the name" of a variable by parsing the expression themselves, you make your code harder to read.
camelCase is superior to snake_case because a variable represents a single concept, not separate concepts represented by a string of words. Adding underscore unnecessarily makes words visually distinct when you're dealing with a single concept. They also add verbosity and length that doesn't benefit anything. Is there an objective argument for snake case being more readable other than it's the convention in some languages (not objective reasoning) (Flame war go!)
Anyway, I could go on with a number of more points. Am I suggesting there's a correct style? Not at all. But you can absolutely use strong and objective reasoning for why one style is superior to another. I don't see people typically apply this kind of rigor to their style, they tend to just prefer one approach "because".
Different people will weight things differently, so can come to different conclusion given same evidence, but there's absolutely a whole set of philosophy and logic you can use to justify style, and it's not explored at all in academia really.
Final note. There is definitely an element of cultural bias as well. People who tend to read code of one style will more readily be able to parse that style. There is no universal truth. But if we all start from the same state, we should justify which styles are best with strong reasoning.
Because I agree with most of it, but you called for a flame war, I'm going to jump in.
snake_case, is obviously the more readable. In fact your point shows this cognitive dissonance we all have to a certain extent. You argued (and I agree) with a lot of details that are important for readability at "first sight", "intuitive layout" etc, and then you go to say camelCase is more readable...
We're not even taking into account people with small amounts of dyslexia in this, but
certainlyThisIsNotMoreReadable than certainly_this_is_not_more_readable
Maybe if you're a foodie person? :)
kebab doesn't allow to do whole selections on most text interfaces though so that's a real downer for me, no matter how much a good kebab is worth
Thanks for this long list. But again, that's missing the point. Everybody has their list of what they do and why. And everybody is pretty convinced that this is how it ought to be and they have good reasons. I'm not saying yours are wrong. But for most of your points, I know people who'd argue the exact opposite. And they give good reasons too.
Point is that we don't have a shared, common, well-defined core in our industry. A list that everybody adheres to. Our lists are not in sync.
The variety of programming languages that people can choose from now does not help either. Standard practice in one language is a cardinal sin in another. Different patterns, different principles, different paradigms. People mix and match freely.
My point is that most people's "list" is not rooted in objectivity at all.
I provide objective and concrete reasoning for why these style elements are beneficial. In the wild I rarely see people justify their style with strong convictions.
Again, different people can reach different conclusions given the same evidence, so there will never be a universally correct way to do things.
But there's also is a lot that's done by convention that's hard to justify objectively.
The biggest faux pas I see is pushing implementation details to the forefront. There are arguments to be made that this can be beneficial in some contexts, such as algorithms where you want a "single pane of glass" into what's happening. But you can also objectively specify those contexts and when a style is more applicable to one context vs another.
So long story short, no, there is no best style. Yes, you can objectively quantify why a style is good or not, and in which contexts. Beyond specific style elements, there is a philosophy underlying the readability of code style and will eventually become a big part of education in software IMO.
Other industries/areas have firmly established standards. Our industry needs those too, badly. Not just for style, but overall for design and architecture.
Maybe it's because software development is so easily accessible that we don't have them yet. To become a surgeon, you need to go to med school for an eternity. To become a construction engineer you need training and government certification. Both areas move slowly, compared to programming. In our industry, a language that's older than 10 years is called "mature" and the hipsters leave it for a younger one. And the next 16-year old can jump right in. That's not bad, it keeps our industry exciting, but it does not allow us to establish rules everybody agrees to, applies and defends.
>I've been consistently amazed at how far companies can get on shoddy code.
I think this was one of the most disheartening realizations of my career. I spent and still spend a lot of thought on how to improve code for readability and maintainability just to realize companies can make a lot of money with crap for a long time.
I think it's more of a correlation not causation thing :)
All else equal, the company with the better codebase will be more competitive/make more money.
But at the same time it's just true that for most companies code quality and technical excellence are not core qualities of their culture. A lot of companies say that it is, but they don't live it... Or the original founder/technical team don't really have the chops to enforce that quality and make it a core element of the business.
Of course that doesn't meant they're not smart. I've known a huge number of highly intelligent people that don't care about code quality, or the future human reader. Needs to become embedded in culture of the org for it to trickle down and become lived in practice.
This is where I shine in start up environments. I can throw together “working” implementations quickly while also having the forward thought to allow the system to be incrementally replaced or improved overtime. My starting implementations can look rough and sloppy, but I use consistent patterns and designs that guide building out more complex systems as we go.
I have also done the opposite of taking an existing monolithic spaghetti code system and start isolating functionality without changing behavior. This then allows to improve and replace sub systems as needed.
If the 10x and gatekeeping people want to give us methods for getting to 10x productivity/skill, I'm all for it. But articles and threads like these always fail to give up a method of reliably training that quality and accurately testing for it.
Until I can hold up a plaque where humanity agrees that I'm a proven 1x, 5x, or 10x engineer and I deserve money and a job according to each of those levels, it's all just posturing and debate.
Unfortunately I'm not sure it's trainable. It seems much more correlated to an individual's personality and drive.
The traits I see in engineers who I consider to be 10x:
Growth mentality. Always try to do things the "right way" rather than just completing a task. Educate yourself via internet/books to understand all points of view on an issue, and tradeoffs of each approach.
Setting a high bar for your work. Never solely focus on getting the job done, always question and focus on what the best way to get the job done is.
Extremely self critical. Don't get attached to your work. Always criticize yourself and question whether decisions you made were correct.
Objectivity. Always quantify objectively to yourself why you made a given design decision, why
did you name your variable X vs Y? Could you justify the merits of your approach to others without relying on subjective points?
Focus on business value. Optimize for what drives business value. Don't pursue projects that are technically interesting that don't provide long run value, for example.
Work with intensity. These people legit code 8-10 hours a day straight. They aren't coding for 30m then browsing the internet.
Never give up. Regardless of how technically challenging or impossible a task seems, they will work tirelessly to find a solution.
Self managing. Can operate 100% independently without constant manager intervention. High level direction still important to align on business goals of course.
Ownership. These people take pride in their work and feel a sense of ownership over their code. They don't need to be asked to step in when something they've worked on has an issue.
It's not about specific knowledge at all, or training.
People could learn to follow these principals, but it's much easier when it's in your nature. I have not seen anyone really change their trajectory from median to superstar before, but I'm sure it's possible with a mentality shift.
> Never give up. Regardless of how technically challenging or impossible a task seems, they will work tirelessly to find a solution.
That is actually a failure mode - the engineer that tirelessly works towards an impossible goal.
The 10x engineer has the critical heuristics/intuition/skill to avoid dead-ends, and also the engineering taste to concentrate on technically hard but possible tasks and the skills to deliver.
> These people legit code 8-10 hours a day straight.
That's physically impossible, unless you're performing some assembly line task like creating a frontend prototype from a marvelapp mock (tons of html, css, js).
Can you do creative work for 10 hours in a stretch, every day.
I would consider myself a highly productive person and I have many of the qualities they pointed out. I can’t program that long, I program in hyper-focused bursts. I have had many coworkers comment/complain that it looks like I’m not working because I’m surfing the web, watching YouTube, daydreaming, etc. But I’m constantly designing, debating, and thinking out how I should implement something that by the time I actually go to code it I know what needs to be done and bust it out in a couple hours. My managers commented on this early in my career because other developers think I’m lazy, unprofessional, or unproductive when I’m usually the most productive person on the team. Working from home removes this problem for me.
> One afternoon, I was bent over a program listing while Wendl was staring into space, his feet propped up on his desk. Our boss came in and asked, “Wendl! What are you doing?” Wendl said, “I’m thinking.” And the boss said, “Can’t you do that at home?”
Averaging around 350k lines of code a year for a few years. This was mostly frontend/product focused work, so there is more boilerplate than in other disciplines, of course.
It's also important to note, the higher quality the codebase is, the less energy it takes to add to it. If you spend 50% of your time reverse engineering spaghetti code, it will be way more tiring than adding to a codebase where design is sound, code is very human readable/friendly etc.
It certainly takes a lot of energy, but why do you say it's impossible?
Been coding about 20yrs, In my case its not as much as the IQ but the ability to switch perspectives. I have seen that when I code or debug for long hours often I lose that critical ability and I often repeat the same mistakes. Eventually I take hours to accomplish what I would in 30mins, thats when its time to wrap up.
but I should point out that long stretches of time are different from quite (context switch free) streches of time.
In my case I was working in a codebase that I largely built myself, so I understood all design decisions and code at all times. It's much easier to operate in this environment.
I have worked on less clean codebases where I spend hours tracing state through spaghetti-like code, and there's no way you can productively code for lengths of time in those environments.
It's always better to refactor that kind of stuff ASAP, assuming the longevity of the product matters, and the refactor is a tangible improvement over the original.
So it was more or less a large solo project? How do you know your code base was much better than those less clean/spaghetti codebases? Your own code is obviously easier to read/understand than that of others. In general it's easier to write code than to read/understand code of others. Developers who are founding members of a codebase are able to navigate it better vs those who come later and therefore able to work much faster. It may give them a false impression that they are genius 10x coder. Then when developer who comes later is not able to be productive, founding developer would blame it on incompetence of newer developer. But it could also be that codebase is of poor quality, but as founding developer you don't see it. It's hard to be objective about your own code.
Now let's go to the reverse situation when you are spending hours "tracing state through spaghetti-like code". It could in fact be that it's actually a great code written by a 10x developer, but you are not smart enough to understand how it works. It's natural to blame someone else and not you.
Not a solo project. I was an early dev at a startup and owned that feature area. Later on others took over the code.
How to judge whether a codebase is
high quality?
Consistency of design and abstraction. Does the code use the same abstractions and design throughout? Consistency is one of the most important things in quality. How many unique concepts and abstractions do you have to learn to understand the code? E.g. in frontend context, do you use the same pattern for managing business oriented state? How is that state updated? Are those patterns consistent throughout your codebase? The biggest problem I see with the spaghetti codebases is they lack consistency in design.
Separation of concerns. What's the blast radius of any given change? If I change render logic, can it impact business logic, and vice versa? A big problem I see is that codebases do not appropriately separate these type of things out. Meaning the code is fragile and it's easy to introduce bugs inadvertently.
Anyway, I can list many points, but I'm on mobile now.
High level indicators would be: How quickly can new devs jump into the codebase? Is it easy to diagram and explain to others how the code is structured? How many bugs come out of your codebase? How quickly can you add new features to that codebase? What is the "blast radius", or is it possible to break something seemingly unrelated to a change you're making?
How do I know my codebase was good quality? I was extremely self critical when writing it and ended up rewriting it a few times before it was in a state I was satisfied with. Number of bugs are extremely low and feature velocity is high, relative to other areas of the code.
I don't think there needs to be a 10x label. It's not healthy to actually call people out as 10x or not publicly, I definitely agree with that.
But the truth is there are people who are insanely productive relative to median, and 10x is just a rough term to refer to them.
I do think it's worth paying those people 2x or more over paying 1x for two median devs. The trick is being able to identify them accurately... that relies on a well honed interview. There's risk in compensating people so highly if your judgment turns out to be wrong.
Certainly definitions won't be universal, but this type of person tends to do very well regardless of the environment/language etc.
Well the label could be anything and the same problems are still around. The same goes for being labeled a software craftsman or not. There's enough flexibility in how we assess peoples' skill that I can accidentally get the label if I just keep trying and the stars align. (This being a genuine, verifiable belief of someone else who's in the field and not me simply lying about what they said). With interviews, those can vary by company and the person giving it. It'd be more consistent if that was focused on a widely known credential and institution that's dedicated to assessing it. When I can take company and people's biases out of it, I can more objectively decide how good I am, what I need to improve on, and what level I should be working jobs at.
I do think certification and credentials can play a much bigger role than they do today.
No, I'm not talking about the BS certifications where you can spend a few hours reading a book and pass a multiple choice test... but something more "elite" and well rounded to give a quality stamp of approval.
It would be a great thing if candidates could go through one process, get that stamp of approval, and receive offers from X companies.. rather than interviewing 100 times. I understand the needs of companies are individual, but most candidates who are "strong" will do well interchangeably at these companies... if it's more of a generic development role.
The difficult thing is that the industry seems very stuck on algorithm and design problems as the sole focus of judging a candidate, which are pretty easy to game (design less so than algorithms). To identify these kind of people you really need to judge real world code and productivity... large projects with more elements of design.
Beyond technical skill, how hardworking is the person? How much will they care? Personality traits like these tend to matter a lot more than specific knowledge.
Anyway... this is kind of a meandering response, but I do believe that in the future we'll have a much better system for interviewing with less redundancy and higher accuracy. The goal is to maximize correlation between performance on the interview and performance "on-the-job".
IMO being "10x" or whatever is not really about productivity or skill, or rather, those are necessary but not sufficient. What it really comes down to is doing the work that makes other developers more productive. In other words, the 10x developer doesn't output ten times as many lines of code or complete ten times as many stories. They simply make everyone else's life a little easier by identifying and working on the important stuff.
>Software is still a new industry. I fully believe the companies that win in the long run will be the ones that have the best codebases (assuming software is what differentiates your business).
There are so many counter examples (Facebook, Microsoft to name two) to your point it simply can not be true.
So your view is that the long run is a few decades? :)
When I say long run, I'm talking hundreds of years. Software as an industry is not even one generation old yet. There are countless advancements that will come.
That being said, I don't consider social networks to fall into the class of an area where your product is the main differentiator. Network effects come first, product second.
Database products are a better example. JIRA another. It's the most widely used now but extremely slow and buggy. I sincerely doubt JIRA will be the winner 100 years from now if they don't improve technically.
In fact, a lot of software companies these days are just competing with traditional companies, but with better software. That's the whole selling point. E.g. fintech replacing banks, uber replacing taxis, insurance companies that make it easy to make claims etc. The bigger the tech disparity, the bigger the advantage.
> So your view is that the long run is a few decades? :)
I suspect that there's almost nothing going on at the Ford Motor Company that has even the remotest connection to anything technical that happened during the early years of the company's founding.
I guess it depends on how much leeway you can be given for using “almost nothing” and “remotest connection to anything technical”, but Wikipedia says Ford Motor Company was incorporated in 1903 and the first assembly line dates to 1913.
Engine blocks are still cast, sheet metal is still bent, pressed, and rolled so I think there is a lot of the original years still around. Yes, I’ll give you that there have been huge advances in sophistication, but it seems to me the early years are still present.
So many good points in this post. But I’ll nit pick this one anyway :-)
>technical debt is almost always created by accident through lack of experience rather than a conscious tradeoff.
I agree with this, at least early on in the business. But my experience is that many organizations eventually realize their technical debt. Sometimes the realization comes so far down the line that it feels like a monumental task to fix and then it does become a conscious decision. “We know the code base is shoddy and needs to be fixed, but the schedule/cost risk outweighs the quality risk.”
>Software is a new industry
In the early 1990s I heard it referred to as the “cave drawing days” of the industry. I wonder if it’s similar to how mechanical systems were in the early days of the industrial revolution. Lots of innovation, very few codified best practices related to pressure systems etc. It seems like the steam era of “move fast and break things”. Eventually, industry caught up and put together standards like ASME codes (or were regulated to do so). I’d like to see this more commonplace in software beyond its current adoption in a few industries
Well there are more productive programmers and less productive ones. It's pretty obvious to me. I don't like trying to quantify it as 10x or 20x, because it's kinda pointless to try and I don't view it as a scalar. I can't program graphics cards, but I can rebuild some of the data feeds that the Nasdaq pipes to hedge funds. I don't think a game developer could do what I do. It's the specialization that really counts, not the raw productivity, but raw productivity does count too.
In terms of your example, yes. The problem with software is that a bad architecture can complete hobble it and there are plenty of cases with unbeautiful code that makes a pile of money. I think there is artistry in software, but that wasn't the primary reason I compared it to music. I was trying to express the vastness of the domain and the range of complexity and how one could find a part in the search space that is simple enough to be called easy. Hence the garage band metaphor. Not everyone is going to be writing compilers. Some people don't want to throw their brain at a heap of complexity all day long. They just want to make pretty buttons that have a satisfying snappiness to them and call it a day.
What I'm trying to say is that there isn't one "programming" and for the people that need to hear "programming is easy, anyone can do it" in order to get the courage to try to take it up, I think that message is good. It doesn't mean they'll be working for Nasa on space probes, but they can make a comfortable living on low stakes stuff and have fun while they're at it.
I think the comparison is quite apt, given that the most popular artists are usually not the ones that have "mastered their craft" the most.
One can argue that White Stripes' 7 Nation Army or Andy Warhol's Campbell's Soup Cans are not feats of technical mastery by any stretch of imagination, but the key is that there is no correlation between technical difficulty and monetary value in the first place.
With that said, it's also worth mentioning that the world is vast enough that there's a bit of everything. Yes, there are companies making millions on the back of terrible excel spreadsheet hackjobs. But there's also Google's impressive infrastructure. And there's lichess.org running a hugely popular app on just a few servers. Success in itself it not one-dimensional.
> One can argue that White Stripes' 7 Nation Army or Andy Warhol's Campbell's Soup Cans are not feats of technical mastery by any stretch of imagination, but the key is that there is no correlation between technical difficulty and monetary value in the first place.
I see arguments like this a lot and it think it conflates two very different kinds of "technical difficulty"—design difficulty and execution difficulty.
Given the sheet music, any guitarist can play 7 Nation Army in a few minutes. It is not physically difficult to play. Also, it's not hard to come up with a completely original melody or artistic work. Just throw a couple of random unrelated things together.
But it is extraordinarily difficult to have such a mastery of composition and understanding of what music is already familiar to people to be able to find a melody that is both original and enjoyable to a wide variety of people. The level of cultural, musical, and historical knowledge required to do that is extremely difficult and rare.
It's like taking your boat to the world's most popular fishing hole and knowing where everyone else fishes so well that you can still manage to stake out an unvisited spot that hasn't been fished out and reel in a giant.
> But it is extraordinarily difficult to have such a mastery of composition and understanding of what music is already familiar to people
The problem with this argument IMHO is that if it were true, one would in fact be able to just bang out hits by developing such mastery. But music hits get popular primarily on the basis of luck, survivor bias, branding, etc, not strictly based on artists' composition skills. There are plenty of very talented one-hit wonders, and even criticisms that popular music is "manufactured" (implying that it is relatively easy to just follow some vague formula of 4/4, II-V-I chord progressions and lyrics about love and end up with something that resembles a hit).
Uuuuh, that's exactly how the music industry works. I think you might be surprised to learn how many hit pop songs were written by a very small community of artists, completely separate from the ever changing faces that perform them.
I mean, it's certainly possible that he is one of a select handful of people that has mastered a skill that almost no one else in history has been able to.
But given how many musicians and producers exist and how utterly small is the percentage of people who are comparable to Max Martin, I think it's reasonable to speculate that his success might be partially/majorly attributed to factors of luck/survivorship bias/branding/popular-music-as-a-mass-produced-product I mentioned.
There's also a certain amount of positive feedback, I suspect - once you've had one hit, people will want you to write for them and, because it probably sounds hit-like (which stands to reason since your style has already been a hit), it'll stand a good chance of also being a hit which means more people will want you to write for them and rinse, repeat, cash cheques for 20 years, etc.
The big iffy assumption being made in your post is that any kind of foreknowledge of the outcome exists. In reality you're probably looking at survivorship bias at work. A thousand artists throw their output at a wall, one manages to stick and rakes in the big bucks.
If the same artist has several shits stuck on the same wall, it's statistically improbable that he's just lucky. White Stripes were not a one-hit wonder.
Price's Law is a thing. It states that the square root of all scientists publish half of all scientific papers.
If you have 25 programmers on a project, it is rather likely that 4-6 of them do at least half of the work. That would be a 5x developer.
Very often, productivity is linked to perseverance. If you socialize and only actually codes 1-4 hours per day, you likely are far less productive than the on-the-spectrum programmer who pounds out code for an entire work day (or longer).
I have slowly managed to train my colleagues that a PR should be "one thing". My team ends up doing a whole lot of internal tooling, so we're frequently creating "new small tool" and one colleague started by working away and only raising the PR when the toll was essentially done.
This, essentially, ends up with a PR review that takes hours to complete, only to end up with at least a few "changes required". Leading to updates, and a re-review, usually with enough time lapsed that the review ends up being "from scratch" (partially due to the size of the PR, partially due to the time lapsed).
We've now mostly converged to "start with a PR just setting the skeleton up and one testable function", meaning that what used to be a single monster PR now ends up as 5-15 PRs, each one much easier to review. Amusingly, this also tends to end up with things being completed faster.
> I don't disagree but the idea of equating software development with some sort of artistry also allows the existence of the 10x programmer as, you know, a more gifted artists. [...] The most horrendous application I ever worked on was a java servlet app where the original developers didn't understand thread safety.
The knowledge of thread safety is not an inborn thing nor issue of talent. It is literally issue of knowledge that you can acquire if you previously did not had it.
And companies can get away with bad code for quite a long.
> I've met a lot of folks who didn't believe it... right until they met one.
That right there is the truth about 10x engineers. We have one in particular I will mention. Sometimes he is a 5x, and at other times he is 20x. This is true and measurable according to the number of tickets that get closed, stay closed, and test as correct. He doesn't read HN, stack overflow, fb, twitter, tiktok, blogs, or emails during work hours. He sits down and cranks out code.
> measurable according to the number of tickets that get closed, stay closed, and test as correct
10x engineers also have compounding effects. These are impossible to measure, but you'll notice them when you see them. They flat out write better code.
Better code fails gracefully, is easy to read and especially nice to extend. Juniors seems to magically be able to ship features really quickly on that particular codebase and onboard really fast. If you dig deeper you'll see the 10x giving hints and feedback.
At scale and with long-term projects it requires knowledge, mastery of tools, foresight, experience, intuition, creativity, planning and many judgement calls.
This is not special. The same is true for many other occupations. Be it carpentry, electrical engineering, finance or, yes, even marketing.
In a lot of ways it is easier than others, because (non-architectural) mistakes can be corrected a lot more quickly, and there is a plethora of (often free) learning materials, knowledge resources, tools and and projects to build on that other fields can only dream of.
I think many programmers have minimal experience with other jobs, and assume that coding is somehow more elevated or demanding than other professions, while the reality is quite different.
> I think many programmers have minimal experience with other jobs, and assume that coding is somehow more elevated or demanding than other professions, while the reality is quite different.
As someone who has worked in a few different fields, this x 100. There is nothing "special" about programming.
I would say there's nothing special about programming compared to other types of engineering.
But professions like Nursing are also quite rigorous in educational requirements, but nurses don't engage in the type of long-term planning required in engineering. I do think the plan-building aspect of engineering adds to the overall difficulty of the profession.
Following an existing flow-chart is different than building a flow-chart.
I agree and that gives you a better framework to improve yourself too. If you think about woodworking as an analogue you'll want to learn about new types of wood, new tools, woodworking design and history, contemporary woodworking design and technologies, try to make every chair you make more perfect than the last, etc.
There's no one true way to make a chair, it depends on who will use it and how you're feeling. Craftsmanship does include art in it.
Code like the Obfuscated C Contest is art.
The code that orchestrates your cloud servers is more like engineering.
Prototypes in language research is science.
Coding competitions are sport.
Comparing it to engineering vs music is missing the point.
The keyword is craftsmanship.
I've graduated and have done work as an electrical engineer, and have become a programmer over the years for financial reasons. Whenever I do engineering or design work, I feel they really are very similar to programming. And they probably are similar to music, although I lack comparable proficiency in that field.
And the key insight for me was: the more you do any of this stuff, the better you become. The time you spend with thoughts about it, or practicing it, it slowly changes you. It changes the way you think, the way you approach the problems. You become experienced. And it does not seem to end, there are always new revelations, and you can always find fault in yesterdays work, that you could probably do a little better today.
I'm a self taught programmer with a engineering degree.
I never really did engineering as a career as my first job out of university was as a software developer.
What I remember from that time and why I think I picked up programming fairly easily was my engineering degree gave me the skills to think through a problem.
I never really had trouble planning out my software designs even though I had no formal training in that area.
So in that sense I agree that these two disciplines appear to be similar.
I put this down to the problem solving skills I learnt through my Engineering degree.
It's intriguing seeing how often we reach for metaphors when trying to define software engineering. Some say it's like music, others like painting, the crafts and so on. What often gets overlooked is that those areas are thoroughly anchored in the physical and sensorial world - one perceives their work and usually physically interacts with it.
For software, one sits most of the time in front of a glowing screen and the rest is drawing boxes and text on paper/whiteboards (plus meetings). Certainly doesn't sound as glamorous and one is left with imagining their work most of the time.
That's why such comparisons fall flat and at least to me it seems that an attempt is being made at rubbing some "cool" on something that is typically perceived as uncool and for a regular human looks mind-numbingly boring.
So programming's not hard because it's like <arts/crafts>, but because it's abstract and mechanical and emotionless. It's an acquired taste which needs fertile ground to develop in, when most people understandably don't have that, not even for a simple stack of JS, HTML and CSS.
I wrote my first program in 1965, and have been programming since then. I got my first job in 1970 with a B.A. and a grand total of a one week course in FORTRAN. The job required writing Assembler on a 32K machine.
> The more and more I code the more I see it closer to something like music than something like engineering.
For many years I've also made the comparison between programming and music. You can learn the theory (CS or music) in school, but to be truly great as either a programmer or a musician takes passion, obsession, and dedication. I'd actually rank obsession as being the most important trait, as it can drive the other two. I'm not saying obsession is always healthy, but it's clearly a key driver in the skills of elite performers in many disciplines.
I think the main reasons behind the similarities of the two is in ease of access and the rapid learning feedback loop. In both programming and music, you can buy enough gear for a few hundred bucks to experiment with your craft to your hearts content. In both, mistakes are cheap, if you play off key or write a bug you're not likely to damage anything in the real world and can get feedback to improve. In both, you can riff off the works of others easily to get inspiration and get up to speed with the latest developments. And feedback is fast, as your ear or your debugger will alert you to either successes or mistakes.
The above qualities basically make a recipe for quick and unbounded learning, which leads to exponential development of skills. This is a recipe for not only quick learning, but the building of intense obsession in the right mind, as the rapid feedback system fuels the brain's dopamine reward system. It's no wonder when we see a young person who's exposed to programming with plenty of free time that we're often amazed at what they create. The same is true of music.
A slight tangent, but my thoughts above are why I always ask people when/how they first learned to program during an interview. A new grad who's been obsessed with computers and coding since age 13 is going to run circles around someone who started in college because they thought it was kind of interesting and their friends told them how well pays. It's a simple question to ask, a nice ice breaker, and can provide a very useful signal for hiring if the interviewee exudes passion in telling you about their coding genesis story.
I think analogizing with structural engineering still fits more than you're giving credit for, at least in terms of how talent does or does not scale in the absence of a formal engineering education. My dad effectively rebuilt every part of our house with only "formal" training as a plumber. My great-grandfather built his house completely from scratch, himself, and picked cotton before that. But neither of them could have built a skyscraper. There's a difference between someone who can build stuff, even incredibly useful stuff, and a true engineer.
Software, for whatever reason, just tends to lionize and monetarily reward hackers over engineers. I'm not exactly sure why this is. Maybe we just get so much more to start with? If you wanted to put up a skyscraper or build another Brooklyn Bridge, you pretty much need to put together all of it. Only the land is there already. On the other hand, with software you can seriously stand on the backs of giants. Someone else already laid fiber cables beneath the oceans, put satellites with radios on them calibrated to deal with special relativity in space, processor makers basically use black magic to hide all of the terrible, inefficient coding we do and make it fast anyway, database engines, exponentially cheapening storage, and CDNs do so much of the heavy lifting of caching and delivering content, and we profit.
I guess skyscraper builders get some pre-existing infrastructure. They don't need to lay their own roads or build new electrical stations or steel mills.
But still, software feels like a business where a lot of people learn quickly how to build their own backyard tool sheds, then go apply to design skyscrapers and get mad when the interviewers expect them to know the principles of physics underlying how it is possible to get 100 stories of steel and glass to not fall over in the wind.
I’ve had a similar thought recently regarding music and programming (I studied music but now work in tech) but from a different perspective. The truly great work is imprecise. It’s not perfectly structured. It breaks the rules. You have to feel it instead of think about it directly. In fact trying to quantify it and make it perfect reduces the quality of the end result. You have to learn all the rules and then throw them away. The more and more I age the more I’m convinced we already have all the answers built in for anything we could wish to explore in this universe but our conscious is mostly incapable of accessing it.
So yes programming can be easy, even the hard stuff, but we can only fleetingly tap into the subconscious which allows it to be easy.
> I've been programming for a long, long time. Went to college for it when I was a pre-teen. The more and more I code the more I see it closer to something like music than something like engineering. Getting a little garage band together isn't hard. A couple years of practice and you and your friends can play at a little bar or at least at a high school shindig.
> The same is more or less true for programming. A simple stack of JS, HTML, and CSS is pretty easy to get going. And if you're content to make marketing sites for advertising companies or similar, then go nuts. That's your simple jam and you rock out on it as much as you like.
Nice point, beautifully laid out! Favourited and added to my quotes file!
Rather than music, I find a much better comparison in sports.
Football is easy. Anyone can gather friends in a court or park and kick the ball for a while. Kids and middle aged fathers do it all the time.
However not everyone can play professionally, say in a second or third division, and earn a living wage out of it.
And still less people make it to the top teams of the first division, becoming millionaires and celebrities.
The ratios are different, but these groups roughly map to people ability to code. Probably most people can "write code" to some extent. Few of those will be able to make a career out of it as professional developers. And yet a smaller number will make it to FANG and other top companies, making 6 figure salaries like it's nothing.
I agree and I’d say the semicolon days are about gone with all the automatic checks done on today’s code.
Compared to what I had to endure when I took my first CS class with Java 18 years ago, typo bugs are far fewer. Beginner programmers lives have been greatly improved by IDE enhancements. Almost too much. In code reviews, I’ve seen stuff that is a brand new language construct. When I ask the dev about it, it’s just something that the IDE suggested as an improvement. “The IDE told me to” is a little scary, but maybe not any worse than a stackoverflow post.
The difference between music and programming is that programmers seems to earn a lot of money.
So a lot of untalented people want to be programmers.
But not everyone is suited for programming and not everyone can be a good pianist. Imagine the state of music in a world with a lot of rich pianists and everyone wanting to be a musician.
Does that mean you studied software when you were 11-12 years old (pre teen: before 13-19 y/o?), together with college students typically 19-25 years old? (Sorry if it's a silly question)
I audited a graduate level VCD course when I was 12 does that mean I can say I have been going to college for VCD since I was a pre-teen? What does it even mean to be a preteen in college?
> So when people say "programming is easy" what they really mean is that it's easier than most people expect it will be for the financial incentives it provides
Consider that to make the majority of the most successful startups of the last twenty years -- Facebook, AirBnB, Uber, Twitter, Pinterest, etc. -- you don't need much more programming ability than you'd get from a six month boot camp. And that's not just to make an MVP, it's to get them into the tens of millions of dollars of profitability. If that doesn't qualify as easy, it's hard to think of what in life would qualify.
Five out of however many hundreds of thousands tried doesn't make it easy. It may not take technical mastery, but it still takes luck. Arts aren't necessarily different. Lil Nas X spent a couple hours on a cheap camera with a few friends throwing a video up on TikTok and suddenly has Billboard's top single of all time. I don't want to crap on the guy's talent. His songs are catchy. But he didn't exactly have to cut his teeth at Julliard. But you don't see people saying truckers should learn to sing and dance.
> I said that the programming field is a fertile ground for beginners, and it is. But what’s fertile for grain is fertile for weeds too, even moreso. And we need to talk about these people, taking advantage of the fertile ground.
Yikes. What a gross, self-congratulatory rant. The author tries to defend against the term "gatekeeping" by getting out ahead of it, but that doesn't change how deeply exclusionary the result is.
It doesn't even stick to a specific complaint; it jumps around to different things that emotionally feel related in the author's mind but aren't actually. First we're talking about boot camps, then we're talking about how StackOverflow is "the scariest thing that happened to the programming community in the past 10 years", then we're talking about "diversity" speakers at conferences riling up "mobs" in some kind of conspiracy against the author and people like him?
Buried under all of this (literally, at the very end) is perhaps a poorly-executed attempt to tell beginners something of value, that it may not be easy now, but you can push through and it will get better. But I don't see any actual beginner reaching that part before getting discouraged by the rest into doubting whether they should be in this career field at all.
You left off the last sentence of that paragraph, which made me interpret the overall sentiment very differently:
> I said that the programming field is a fertile ground for beginners, and it is. But what’s fertile for grain is fertile for weeds too, even moreso. And we need to talk about these people, taking advantage of the fertile ground. And where there’s plenty of beginners, there’s plenty of people taking advantage of them.
That is, I interpreted "These people, taking advantage of fertile ground" not to mean subpar newbies who can't cut it (which is how I read your interpretation), but instead to mean the snake-oil salesman/huckster types who take advantage of these newbies by sort of implying "hey, just come to our 30 day bootcamp and you'll be a programmer, just like those programmers who make top dollar at Google and Microsoft!"
I actually generally largely agreed with article, and I didn't find it gross at all. Yes, programming does have a low barrier to entry, but to become a true expert at it takes the same level of skills and preparation as, say, a doctor or scientist. But you don't see any "Become a doctor in 30 days!" bootcamps out there trying to convince people that "Hey, anyone can become a doctor!"
> There are many ways this happens; some of them are not even aware that they do it, they are just instinctive hustler that oversell their own skills. Usually you see them: two years of experience in software development, writing books and giving advice, sometimes at a hefty price. You see them at conferences, or with articles promoted, or with other types of media, sometimes playing the diversity card, at other times the beginner card, pushing their way in and taking advantage of credulous mass of beginners.
So the "weeds" are still beginners, just beginners who the author perceives as overselling their skills. That isn't much better, in my view.
It might be unpopular to say, but I think underqualified people giving unearned advice, and flooding the job market, is indeed a huge problem. I don't think it's gatekeeping to call it that.
> underqualified people giving unearned advice, and flooding the job market
If they're speaking at conferences and getting published and working on projects that are out of their depth, then it's on the conferences and publishers and employers to identify them as underqualified.
If they're "flooding the job market" and working on things that are appropriate for their skill level - which I would guess the majority are - then that's a good thing, even if their skills are at the low end.
So you're saying that conferences and publications should act as.. gate-keepers? It sounds more like you disagree more with the tone of the article than the actual substance.
You're intentionally giving a bad-faith interpretation.
The term "gate-keeper" is colloquially used to refer to those who needlessly prevent or discourage others from participating at all in an entire hobby/career-field/community.
Conferences and publications and employers should absolutely filter candidates by their actual ability to do the job they're being paid to do; nobody in their right mind would suggest otherwise. But this is a) a temporary condition of the individual's ability at that particular time, b) relative to the specific task at hand, and c) just one piece of what it means to participate in the field as a whole. A person might not currently be fit for programming job X but simultaneously be capable of programming job Y, and in the future they might even become capable of X. They might not even be capable of any paid programming work at all, but in the meantime should still be welcome to learn and to hack and to participate in the community.
Of course I didn't really need to explain all that, because you knew what I meant and chose to frame it differently, but there you go.
> The term "gate-keeper" is colloquially used to refer to those who needlessly prevent or discourage others from participating at all in an entire hobby/career-field/community.
Disagreed. That term is frequently used for anyone that isn't an overly positive cheerleader.
Why is this always discussed only in relation to programming? Is being a doctor hard? How about an architect? Lawyer? Welder? Car mechanic? Airline pilot? Are they all gatekeepers if they say their job is hard?
There are different jobs labeled as programming, some easier, some harder.
Where does this narrative come from that programming at all professional levels must be easy for everyone, else you are a gatekeeper? Is it anxiety about future automation and the idea that the only remaining jobs will be programming?
The answer to that is in the article. The information is accessible. It is possible to become a programmer without any formal certification, all the information is out there.
AFAIK all the jobs you mentioned need a formal certification. You can't become a doctor without going to med school. You can't become a lawyer without passing the bar.
Even if you don't (not sure about a car mechanic, depending on the country), it's a lot a harder to get your hands on a car to tinker with than it is to download some framework and watch a get started video.
That's what the author said with programming is accessible. It is very easy to get started which is often misrepresented as "it's easy".
No one would say "becoming a doctor is easy" because you're never gonna be a doctor from online documentation and YouTube videos so there is no incentive to frame it that way.
Alright. Programming is like soccer. The barrier of entry is very low, but it doesn't mean every poor Brazilian kid will be a football genius. But they sure won't be golf world champion.
I grew up relatively poor in Hungary. Programming has been a great path to a good job for me, while it would have been more difficult to earn the same as a lawyer without connections.
Programming levels the playing field compared to gatekept jobs where you must be born into a dynasty to really make it. In that sense it's easy. But it will still only be a part of the population who are well suited to do it.
> it doesn't mean every poor Brazilian kid will be a football genius
This analogy always comes up in relation to programming, but I think it's not quite right: you don't have to be the equivalent of a "football genius" to be an effective programmer. If there was the same market for soccer players as there were for programmers, a lot more people would be professional soccer players - there are so few, and the ones that make it are so far ahead of everybody else, because there just aren't that many spots available.
Well, what regulates the amount of available spots in professional football? Why can't people create additional teams and play exciting matches that draw paying audiences? Is the bottleneck that spectator attention is already maxed out?
But yes, the analogy is faulty if the bottleneck in football is the availability of the spots, because in programming the bottleneck is rather the availability of good enough new hires. We may be around the point where CS programmes have grown so much over the years that the marginal additional student may not have that good potential any more (out of a combination of motivation and talent). But a potential reserve talent to tap into could be women, but attracting them to programming has been an uphill battle and is a can-of-worms topic why.
> what regulates the amount of available spots in professional football?
You're only allowed 11 people on the pitch per side. Believe me, if it were possible to replace Ronaldo with a thousand less-skilled players paid a fraction of his wages, somebody would have tried it.
You could even suggest hiring them for fractions of a match on an internet employment brokerage platform. Footballr.
To be clear - I agree that programming is hard (or else I'm REALLY stupid), but comparing programming ability to athletic ability always seemed wrong because the world needs WAY more programmers than it needs athletes. I'd guess that there are more professional programmers in the world than professional athletes of any kind. If the "market" for athletes were as broad as the market for programmers, you'd see a lot more comparatively mediocre athletes making a comfortable living at it.
I'd say what regulates it is that the quality bar is so high, that the low level is just not exciting. We've become accustomed to the high quality, and now expect the extreme performance and wild stunts the pros manage to pull off.
The same happened with other artistic endeavors. Few people these days really want to see an amateur sing or play an instrument. We have so much high quality music that doing it "okay" doesn't really cut it anymore. Before an okay player/singer might have added to a party. Today, most of the audience will be just waiting for it to end and for somebody to put on some decent, commercial music.
Isn't this happening in programming too? Just like anyone can play Ed Sheeran on their wedding and pay one guy to handle the equipment, companies can buy (or download for free) lots of plumbing tools and frameworks made by the few star companies. It's not like the n+1th website needs professional programmers. For tons of (otherwise offline) businesses tweaking a WordPress site is more than enough.
And just like you can watch Ronaldo on TV from half way around the world instead of watching your town's crappy teams, you can also use Google and Microsoft software and services instead of hiring someone from your town. Even very custom software needs fewer and fewer people due to existing tooling.
So the bar is going higher and higher in programming too.
I'm saying sports, arts and music got to such heights, that an ordinary person can consume nothing but the best 0.1%. This in turn means the demand for the rest has plummeted, and being the guy who can play guitar "okay" doesn't really excite anybody anymore. There's a market at the very high end, and nobody wants to pay a cent for anything below that.
Programming is going the opposite way, if anything. There's lots and lots of programming grunt work that just needs to be done by somebody and doesn't take any particular skill. There's rather less need for wizards able to squeeze every possible bit of functionality into 64K, because at this point resources are cheap.
At this point a programmer can get by with being moderately competent and doing little other than gluing frameworks together. Things like music are the opposite. Mere competence is nowhere near enough.
But to effectively use the plumbing tools, the companies need programmers! And in the near future, there will not be any "automation" of your complex business needs. Every business is different, and every business has different programming needs. At a certain level of scale and complexity, i.e. no longer a mom and pop shop, you need to hire programmers.
> Why can't people create additional teams and play exciting matches that draw paying audiences? Is the bottleneck that spectator attention is already maxed out?
People do create additional teams and play exciting for them matches. That is how amateur leagues work. People create whole additional sports and compete among themselves in them.
The spectator attention is really maxed out, because spectating sport is massively social thing. People do it because of excitement of who win, but massive part of it all is being part of culture, having common topic with friends, feeling like member of big fan club etc.
Programming is not like soccer and golf, because people with great talent and skill for soccer and golf are all over the media. People who do not have major skill can look at them and compare their own skill level.
But I think the OP (unintentionally) makes a telling point, which is that accessibility is confused with simplicity.
We're seeing this in medicine now. Anyone can Google whatever so they're go to their doctors with Dunning Kruger on max and and say things that are really really stupid.
Or they try to understand what's happening. And because they're spending hours on something the doctor spends a few minutes on, they - occasionally - manage to have an insight the doctor misses.
Either way, medicine isn't quite the ineffably mysterious occupation it used to be. Of course it's not really any less complex, but the wall has been breached a little.
The arts are similar. It's easy to buy some paint, so everyone has a go. It's easy to buy a guitar or synth and a DAW, so everyone has a go.
The skill and learning required to be an expert becomes invisible because beginners try things, get unsophisticated results that make them happy but are a long way short of the real thing, and think "Well, that's not so hard."
The problem isn't verbal gatekeeping, it's the lack of media representation of high levels of skill and professionalism. They're either portrayed as unimaginably mysterious, as soapy and trite (see most legal dramas), or as "And you can too..."
There are few realistic depictions of the skill, knowledge, and practice required to be a professional in any field. Or of the insights and perceptions that professionals experience, but which untrained people don't.
> There are few realistic depictions of the skill, knowledge, and practice required to be a professional in any field.
YouTube is pretty good for this, both educational channels and edutainment (like Computerphile) and candid videos of people sharing their professional experience. Or code-alongs etc.
It's definitely the poor man's "good job" (I say that as a poor man) - med school is just not accessible to most people. At the very least, it's not accessible to the poor without laser-focus and being very lucky for about 15 years between about 15 and 30. Oh, and living on scraps.
> "because you're never gonna be a doctor from online documentation and YouTube videos"
You're not gonna become a legal doctor, but I assure you that online you have many many information and videos that teach you the same as they teach you in university. You just need to organize them - and probably some are already part of current pandemic forced online classes
The complicated part may be to obtain corpses to make the practices... /s
I would argue that those corpses(or whatever it is they do in med school) are quite important. I don't think any amount of "book-smarts" can override actual practical experience. At least for me, I can't imagine I would be able to write a program if I had read several books but never opened a code editor.
I believe it must be similar for doctors. Even if you read about lots of diseases and their symptoms, how do you go about diagnosing diseases with complex, overlapping attributes without any kind of experience besides what you read in a book to relate to?
> You can't become a lawyer without passing the bar.
In states where you don't need to go to Law school and anyone can pass the bar, doesn't this make the field accessible? The bar cost $100-$1300 depending on the state + travel costs which is not that far from a good laptop cost to do any meaningful programming.
You'll probably need a $200 laptop and an internet connection. You can do paralegal freelancing in the same way you can do small programming jobs.
Edit: Writing is also accessible. Accounting is also accessible, though if you are becoming a CPA you need some college credits. Online marketing is accessible. Trading is also accessible. All of these can be done from the comfort of your couch and only need a laptop with an Internet connection.
But that's beyond the point, right? The question is whether it is accessible. Which for some states it is, and could be done by reading material. The same can be said about programming and software development.
Test being difficult is not a problem, we want our lawyers to be competent, after all. The more important part is if it is fair. In Poland bar exam had been famous for near impossible questions, which were only answered correctly by applicants that knew them in advance, which typically were family members of already practicing attorneys/judges.
The information is accessible for any other profession really - you talk here about politics not about knowledge.
You can learn to be a doctor or lawyer on the internet for sure. Can you practice it ? It depends. Some self learned programmers can't get a job in some companies too because they don't have formal education.
I'm not sure. I've been both a pilot and a software engineer and the narratives are very different. I've also helped people get into both fields (owned a flight school, mentored programmers).
I don't think I've head anybody say "Anyone can be a pilot!". Becoming a pilot is inaccessible. There are medical qualifications. It's expensive. A degree helps a lot (or is required) for airline jobs.
Self-limiting beliefs keep _some_ people from being pilots. So there are outreach events (Young Eagles being one) that introduce people to flying. The military recruits at events. But it's more this "maybe you could be a pilot. just consider it." vibe.
Programming is accessible (as the article points out). I spent less than $200 in materials to get a good job as a software engineer. (Throw in $500 for a computer if you want). Self limiting-beliefs make up a much larger component (but not all!) of why people can't become professional software engineers.
I think this leads to people overreaching during the outreach phase. If it's only a few hundred dollars, focus and time, then the only thing stopping you is yourself! Well, no.
Let's just start at the left end of the curve and acknowledge there are adults who can't count to five. They're humans, they're people, they're part of "anybody", but they absolutely will never be programmers. And then it's just a spectrum from there.
The reality (like most realities) is more complex than can what fit on a sticker. Some people think they can't program, but could. You don't have to be great at math, but it can help and they're similar mindsets. An expensive education isn't required, but helps with careers.
Programming is hard. But maybe you can do something harder than you think.
The reason why it always comes up is because programmers are relatively well paid yet nobody really understands what we do.
Therefore you get these really silly memes such as if a factory worker's job is outsourced, you can just retrain them to be a programmer. Or the only reason why some downtrodden group is not a programmer is because they were prevented by someone from being a programmer.
The thing that is ridiculous about the memes is that programming is the only field that is completely clear of gatekeepers. You don't have to go to college to be a programmer - the top programming coursework is available online for free (or nearly free). If you want to be credible as a programmer, there are plenty of open source projects that would welcome you. Compare that to doctors or lawyers which really do need college degrees and certification.
I feel like this is also top-down status anxiety from the traditionally high-status people (lawyers, doctors, academics, managers etc.) who really don't like that these prole nobodies are suddenly making good money, without being properly embedded in the elite caste and their manners. So they keep kicking and biting down to say how what we do is really just some blue-collar monkeying around that any janitor could do starting tomorrow, and the real, hard, serious jobs are still in their realm.
It's not clear of gatekeepers, they're just moved to a different point in the process, and scattered about the industry. You don't hear about doctors being given a mystery patient and forty-five minutes to save their life using only a whiteboard; once you've got the qualifications, they're not subject to anything like the same level of challenge.
"You don't hear about doctors being given a mystery patient and forty-five minutes to save their life using only a whiteboard"
That's actually a pretty accurate description of what doctors have to do, at least in the UK. For the first nine years after finishing medical school, doctors have to take a series of exams, including written exams and practical tests, which are primarily diagnosing and proposing treatments for real ("mystery") patients. This is a centralised process, rather than ad-hoc tests at every interview, but doctors do have to continue demonstrating their competence during their careers.
The centralization is the critical difference, though. Lots of professions have ongoing exams. Programming is different in that there's no institution to set the exams, so instead we have ad hoc tests of dubious reliability, repeated for every interview.
That's an interesting point. How are doctors evaluated if they move to a new city or something? How do they know if the candidate is a good cardiologist? Is it purely based on their CV and their previous roles? I admit it's absurd to imagine that a cardiologist would be asked to label parts of the heart (~fizzbuzz) on a diagram at the interview. I also don't think they look at outcome stats of their patients.
Or is it mainly based on who they know and who recommends them?
Maybe the different in processes means that their diploma, medical license, and other certifications means they've been effectively whiteboarded already and do not require re-testing along those same lines.
Would be interesting to consider if it's possible to administer a whiteboarding exam on programmers once, and then consider them solid on the concepts tested if they pass. And if not, then why? Does that mean whiteboarding as it is practiced now is insufficient? Because it certainly seems like for engineers who switch jobs every 2-5 years, they have to be whiteboarded again even if they've had prior experience, even at larger corporations known for rigorous interview practices.
It's as if this industry lacks confidence in its own employment standards, unlike the medical, legal, and other accredited fields.
Another example is language certificates. Maybe less well known to the monolingual English speakers here, but jobs in non-English speaking countries often have the requirement to speak English for business contact, to read professional reference material etc. There are many exams and certificates (local ones, or international ones, like TOEFL, IELTS, etc.), and they are nice on a CV, but they will always do a short test if you can actually speak the language. Passing a standard test is not always enough.
It may also be the fact that doctoring is more about keeping a large amount of facts and experiences in mind as condensed expertise, while programming is more about raw intelligence and solving novel problems analytically (although this sounds a bit pretentious and self-important, I know). Cardiology is very unlike logic puzzles. Now sure, day-to-day programming may also not be much like logic puzzles, hence the endless criticism of whiteboard leetcode interviews.
I think the question might be "why might someone gatekeep at all?"
As a software developer, I love working with developers that are competent, and especially if I'm learning a lot just by being on projects with them. I do not love working with developers who actively decrease the quality of the code base because they do not understand what quality is. Now, that can be relative, and subjective. I'm quite open to junior developers trying things, asking questions, requesting code reviews, etc. But some people get a senior title and a confidence about their work, and charge ahead generating extra work for those around them. So I'd rather such people were, perhaps, not in the field at all!
In general, though, I would like to encourage lots of people to try programming. From my perspective, it's super empowering, interesting, deep and can be a great career choice. Try it, and if it interests you, and you find yourself driven to improve, learn new things, and seek mastery, we're really going to enjoy having you here in the field with us.
There are aspects of programming that almost anyone considering the field could try and learn and see some success at. But it helps to understand that you may discover your own limits (whether by talent, motivation, or opportunity) sooner or later in the field, because there are aspects that are much less approachable. Do you want to spend countless hours preparing for algorithmic whiteboard interviews? Do you want to bury your head in code while stepping meticulously through a debugger on a squeegee hunt for an edge case? Do you want to optimize relentlessly when the scenario requires it?
If software is eating the world, we'll need a lot of developers. And we'll want some that are happy to do grunt work while others forge into the most treacherous waters. But we don't want you to think that all software development is easy, because it's not.
> I think the question might be "why might someone gatekeep at all?"
We'd always go through the same thing with folks who were new to interviewing with a candidate who couldn't quite cut it.
In the following discussion they'd be hesitant to say no and maybe go into how they seemed nice or whatever. Then we'd ask "Ok, would you want them starting on your project with you tomorrow?" Well, no...
I'd venture this guess: because programming is presented everywhere as something easy, with a ton of "hello world" tutorials which don't even begin to scratch the surface. "Everyone can do it" is thrown left and right. Man are they in for a surprise, when they are introduced to tons of poorly written legacy code used by, say, critical medical systems. Think spaghetti code and text-file interfaces with dozens of systems but on a whole new level, likes of which is hard to even imagine.
Damn right, programming is hard, and it is getting harder with every line of code people write.
Note: in this example, I bunched programming with maintaining together. If you only write code for new features without taking into account existing or legacy code, you're a lucky son of a gun.
> I'd venture this guess: because programming is presented everywhere as something easy
I'd say that's an overreaction to the default presentation where coders are genius wizard wunderkind hackers from the movies. I don't know about your experience, but whenever I say I'm a programmer (or more directly translated "informatician") in a mixed group, everyone thinks that' must be rocket surgery.
Perhaps kids in specific countries now grow up being told that it's easy, but I think the 25-30+ years old cohort thinks programming is hard and only for the really smart people.
I have found welding to have a similar community mindset to programming, for some people it's a job, for some it's art, most people think it's too hard for them, getting into it is easy and mastering it is hard.
Car mechanics too, run of the mill mechanics shop doing oil changes doesn't require that much to be competent at, but that's barely scratching the surface. Within the mechanic profession and you can go all the way from oil changer to mechanical engineer. Consider motorsport workshops, specialist restoration workshops, custom fabrication, aero design, engine building, machining, performance wiring, ECU tuning. It's a huge topic.
I find that is the case with almost anything though. Very few things are all that shallow. I have to remind myself of that if I disregard something someone enjoys. Sports fans? Yeah some of it could be shallow, but sports nerds go hard, there is crazy depth to sports fandom. Same with TV shows, video games, telephone pole enthusiasts.
So I guess my overall point is, the question "Is X job hard?" isn't really answerable, since we don't know exactly what part of the job the person is targeting from the question.
The people who are doing the work in programming are not assertive on average and are prone to be taken advantage of.
This is not a criticism; in a way you need to isolate yourself from realities of human politics to be successful in the field.
So in the last decade many socially dominant people who smelled the money have invaded open source. They have realized that you can make a living by posing as team leads and not doing much.
The real workers have let them in, have given them power and are now facing the consequences (ha, finally we can use that term, too!).
Other professions like law and medicine aren't remotely as naive. They are acutely aware of power struggles, protecting their professions and won't let this happen.
Completely agree. If I had a dime for every project owner, project manager, team lead, or <insert made-up job title> I’ve worked with who has absolutely no technical experience or knowledge I’d have over a dollar already.
These people invariably majored in something like english, dance, or music studies and then wind up doing project management because, as you pointed out, they’re after the money and no one is stopping them.
Our profession is misunderstood by the public, and some effort is required to let people know that this is in fact high-skill, demanding work.
Recently, a non-technical executive berated me for not working faster. I wanted to tell him, "would you say that to your accountant, who just worked an 80-hour week to help you meet your obligations on time, continuing to receive new spreadsheets all the while?"
Key insight. In a field with such a deficit of excellence, you can’t be exploited without your own buy in. Except maybe with certain classes of visa troubles.
I think this is typically heard in response to people suggesting "learning to code on the side". You don't hear suggestions of "learning to become a lawyer/doctor on the side". Why is that?
I guess it's probably a combination of software development not requiring a license and people believing that it's easy to learn.
Anecdotal but I know a few people who became lawyers on the side by studying the graduate diploma in law part time and then changing careers. It’s not as common, but it’s not as rare as you’d imagine!
Maybe the difference is that most/all (I don't know about welders, but I guess) of those jobs have literal gatekeepers, i.e. you need some certification to do it.
I have a friend who is a surgeon who says he hardly uses anything he learned in medical school and that he could teach a carpenter to do his job. (I think he is exaggerating a bit, but it's a funny anecdote).
Most of medicine is relatively routine. A surgeon's skill isn't so much in the 99% of cases, but the 1% that have adverse outcomes. More importantly, their skill comes in identifying the possibility of adverse outcomes and preventing them from ever happening.
Me and you could easily be taught to do a routine surgery, like an appendectomy. However, we wouldn't be able to identify if something requires more treatment or prevent a patient from dying if things don't go perfect.
Isn't it very similar for programmers? I don't get paid >100k for knowing how to create a button with boostrap and jQuery, but rather for the 1% of the time where I need to do something 1000x more complicated
I'm sure he's using the fundamentals he learned in med school more than he thinks, but yeah everything in psychiatry, pediatrics and obstetrics most likely not.
> programming at all professional levels must be easy for everyone, else you are a gatekeeper
I've literally never heard anybody say this. Best I can tell it's a straw-man the author has stood up.
Part of the problem is the ambiguity of the words "easy" and "hard", which would be a valid discussion to have, but the OP didn't really seem interested in that aspect, and chose instead to interpret things in the least-charitable way possible.
I think it's literally because those other professions have strong gate-keeping institutions (licenses, etc), and programming doesn't. For better or worse I think that influences the perceived difficulty and prestige. (Note, I'm not suggesting that we need gate-keeping institutions, just that they do have an effect on how professions are seen).
I think programmers are also sort of at fault for this. How many people try to increase their perceived status by talking about how some hard thing is actually super easy to them? While it might elevate their status among their peers, it reduces the status of the profession as a whole (granted in microscopic increments, but still, if a project manager hears "this is easy" all the time, they're going to start thinking these things are easy).
Finally, I also think as a profession we don't do a great job of just presenting ourselves as professionals. How many coders (myself included) tend to look like slobs all the time? If you watch TV, all the other professions look sharp, and anyone tech related tends to look like they just climbed out of bed. Just saying, perception matters a ton.
I honestly think that there are many people who exaggerate how difficult programming is. And people really like to think that if you already dont know a lot, then you are naturally crappy and cant learn. The professions you mentioned require a lot of learning. The expectation is that you go to school knowing what high school taught you, then you learn basics and then you continue learning on your own. The expectation is that there is learning curve.
I think I am good programmer. When I was younger and considering it as a profession, I was told that it is hard and that I should think twice seriously before comitting myself to it. That som of the guys that are already coding are very good and I will compete against them.
There is gatekeeping related to claimed difficulty. There is also perception that either you know it or not, but that you should not expect learning curve.
Also, passionate people of all kinds of professions trying do this exact thing. Whether art or tech or sport, adults go out of their way to signal to kids that "you can do it too, join us doing this thing".
It's not usually an issue with those professions, where there are more reliable mechanisms both to observe the consequences of not being good enough, and to reject those who would produce such work. Also, there is zero barrier to entry for programming. These are powerful differences.
There aren't people out there saying those jobs are "easy" and anyone can do it in the way we have for programming. So why would it be discussed with those other jobs?
The examples you give in support of your thesis are strange. The idea that programming is hard is about as pretentious and wrong as saying that being a doctor, architect, lawyer, welder, car mechanic, or airline pilot is hard.
Almost anyone with a basic level of intelligence and the willingness to put the efforts into it can learn any of the above professions, and programming is not different from them. It's not hard, although there are some hard areas you'd like to get done by a CS graduate or an engineer.
There are professions that are hard or simply require some special and maybe rare talent, but like most other professions programming is not one of them.
What? You enumerated some of the hardest professions in the world and dismissed them as "not hard"! How many car mechanics you've seen turning into architect? How many developers you've seen becoming lwayers? How many lawyers became doctors?
If one doesn't have drawing talent and sense of perspective, becoming an architect is almost impossible. No amount of work will fill for that.
If one gets lost while moving in 3D, no way they'll become an airline pilot, ever.
If one doesn't get mechanics and principles of how cars/engines works and has a talent for working with literally dozens of tools, they won't become a car mechanic ever.
Some of the hardest professions? You've got to be kidding me...
OP could have mentioned sculptors, theoretical physicists, athletes, or singers but chose to list completely normal professions. Just like programming.
But the biggest mistake of this pretentious article and the whole thread is to talk of programming as if that was some uniform profession. It's ridiculous to assume that making an iPhone app requires the same skill set as programming a rocket guidance system. Maybe the self-proclaimed gatekeepers of "programming" like the author of this blog post should start by actually creating a profession called "programming" before they try to gate-keep it.
Hard or easy, does it matter? There are a particular set of attributes that are required to be a programmer, I've asked people who've started to be a programmer and given up - some of the reasons are:
- There's too many things to remember, this is true, there's a lot of stuff you have to remember
- It's so boring, I have to sit all day at a screen, this is true - if you don't have an internal representation running in your head and enjoy doing that I can see this would be boring, the tinkerers mind I call it
- Its too hard, something happens and you have to find out what, who cares? probably related to the previous points.
- I don't like puzzles, something I've noticed, if you don't like solving puzzles, then programming probably isn't for you.
Probably more, any others people have noticed?
Edit: maybe I should say solving puzzles - not necessarily game sorts of puzzles, but more a sense of hmmm, what happened there? and the determination/ability to solve it, not just throw up your hands.
I am really bad at puzzles and dislike solving them. Just can’t be arsed, there’s nothing at stake and the lack of reward is boring.
Been programming since I was 9* and it’s the best thing ever. Precisely because it’s full of problems worth solving. There’s a reward beyond “You figured it out”, maybe you’re the first ever to figure out this particular puzzle, it something starts working that wasn’t before, or you do a thing that previously was impossible.
But puzzles? Meh
* that’s a good 24 years of writing at least a little code almost every day
Strongly agree. I've played every kind of esoteric video games except for puzzle games and I've never solved a Rubik's cube. But ask me why I like programming "oh, it's like solving all these different puzzles all day long!".
This is so true of me. Never really liked solving puzzles, cubes, riddles etc. But programming, oh boy I Love it. Have spent hours non stop debugging complex things in OS, Networks, Distributed systems etc. The feeling of solving it at the end is a small dose of drug.
While I agree that, in practice, programming is most popular with people who like puzzles, I think this is actually the result of bad tools. We will all run into actual real-world puzzles from time to time ("how can we fit this large operation into this small time envelope"), but generally the problems I have to solve are not puzzles at all. It's clear what I need to do and most of the puzzling is how to get my tools to do it. With more mature tools, I only feel like I am solving puzzles when I am trying to pull a rabbit out of a hat.
I suspect the puzzle point has more to do with the kind of puzzle to be solved than solving puzzles in general. Word puzzles, dexterity puzzles, progressive discovery puzzles, etc. Each of them has a very different appeal. For instance, a really quick way to annoy me is to through a word puzzle/game at me ... ( figuratively of course ...)
> I don't like puzzles, something I've noticed, if you don't like solving puzzles, then programming probably isn't for you.
Maybe what you meant by "probably", but I've seen my share of fantastic developers that hate programming after hours, and hate solving puzzles if it's not part of the job.
Not sure what it speaks to. Might just be I've run into more "programming is a job" types than normal.
Maybe. I do tend to take lists like the one above as heuristic rather than absolute. One that I've noticed that's semi-related to puzzles is games. Board games, card games, tabletop games and video games all tend to get more interest in programmer circles. So maybe the puzzle rule of thumb is satisfied for someone who hates crossword puzzles but loves Eurogames.
Me, I don't like solving logical puzzles for play anymore since I started programming. I could always program instead and make progress in something real :)
So my preferred games now are the fast exciting kind, and often language-related like Taboo.
I find that often you’re right about enjoying things like puzzles, math problems, riddles, those little 3D wooden things, crosswords. It seems like a lot of programmers enjoy those things. Except for me. I hate most of those things yet I love programming.
Programming is a creative endeavor for me, whereas puzzles seem pointless for some reason. I finished the puzzle, now what? The same goes for computer games.
With programming I often have created something that didn’t exist a few minutes prior and that is such a joy.
There's a tangible benefit to programming, e.g. I just automated this process and now it runs daily and I don't have to worry about it anymore for the 99% case.
I don't think your list proves very much, if anything.
Nearly every field requiring commitment gets a negative reaction of this sort. What fields aren't boring 'til you get them? What fields don't require memorizing things? At best, you're talking any field requiring thought but even there, lots people give up on intense thought, until they one day get it.
Programming may still be hard, but it certainly has become less mathematical and less low-level, therefore more accessible. I recall that people talked more about Knuth's books, compilers, and OS before 2010. We have less such discussion now. Similarly, people talked a lot more about consistent hashing algorithms, log-structured merge tree, merkel tree, B+-tree, and etc in the early 2010s. I used to read Hacker's Delight and find it useful in my daily work, but not any more. As times goes by, "hard" concepts and algorithms are packaged into well-designed products, and engineers will focus on building products. The complexity can still be there, but they don't necessary have to do with hardcore programming concepts.
That’s a good observation: I think you’ve observed not a change in programming itself, but a shift in the kinds of things large numbers of programmers are building that get talked about on sites like this. Other forums that I track still talk about the deeper aspects of programming, which reflects more on the community and it’s interests than it does any fundamental change in how hard programming is.
The thing is, much of the skills it takes to be a decent programmer are skills that we should endeavor to teach to and instill within everyone.
These are things like:
- attention to detail
- development of a sense of when attention to detail is very important and when "just about" is reasonable
- ability to communicate a process in words, especially written words
- ability to identify patterns and recognize that one has identified a pattern (pattern recognition is automatic in animals and especially humans, but it is often occurring subconsciously)
- ability or willingness to ask "why?" and follow that answer far enough to understand the basic reason for something
- willingness to challenge status quo when the eventual benefit may be worth doing things differently
- ability to consider multiple factors at once (time, cost, effort, etc. etc.)
I could go on and on. Suffice to say, much of what makes good programmers/developers are attributes and behaviors which make good humans. Sure, if for example you have a huge inheritance, you could probably get along fine doing absolutely nothing difficult or productive or creative, but that's not really living. So human life involves a lot of the skills on this list.
I disagree. These are things everyone can apply to their jobs.
Being a programmer involves understanding how computers work, what makes them interop, how networks work, perhaps some basic understanding of electronic engineering concepts, the ability to keep mental maps of insanely complex callgraphs in their head, etc.
This is not something "everyone" can just pick up and do. To reduce programming to a set of soft-skills is what got us into this mess in the first place.
I think the same thing, but most of the hard skills you listed like understanding computers/engineering/networks are pretty irrelevant. Those all can be abstracted in many situations.
Working through complex mental maps is all you need. Thinking through all possibilities and edge cases, and logically ordering instructions to represent a mental model. It's similar to chess where you have to evaluate every possible and unexpected scenario. If you're good at chess you'll almost certainly be good at programming.
If "programming is easy" for some people it's because this one skill comes naturally, and beginners should be made aware of that before they get unrealistic expectations.
I disagree. Knowing how memory works, how a CPU works, what Multi-Processing is, etc. are all pretty vital in being a decent programmer - yes, even for the web: if you don't know that Javascript contexts run single threaded (in the UI thread) then you run the risk of writing hugely unperformant code.
They don't tell the audience this otherwise they won't be able to fleece them. "It's so easy to make apps" "Learn X in 40 projects".
I think the problem is also compounded by people who mostly have superficial knowledge of programming (a few frameworks here and there, couple languages etc) and are in the software industry and carry the title of programmers and engineers.
Programming as a topic is a iceberg. Pick some flavor, find some tutorials, accomplish some small things and it's easy to think the rest of the industry is just that process * 10 every day.
In reality, it's that process * 1000 plus the addition of a few other processes those tutorials can't expose because they're only needed at the intersection of 50+ different applications. Plus an entirely unaccounted for process in the form of creative problem solving that makes up 90% of the work.
I've had a number of executives plop down at my desk, proudly proclaiming to be a python dev only to see their eyes glaze over and every other word fly above their heads only a few commands into the interpreter.
When you have websites like hackingwithswift and you see Chris lattner (who is some genius because he made a new language) endorsing it with lavish praises, you tend to believe that it’s easy. But then every time I tried to make a 10% decent app, I had to look up the documentation and used to be confronted with (gatekeeping?) jargon like concurrency and background thread. I even paid for raywenderlich’s annual subscription but now I realise why these websites are so flashy and captivating.
There are also a lot of resources which sound as if they would be great as they have big name authors but they actually make you more depressed. I had many such experiences most notably with Stroustrup’s books. The one called Programming - principles and practice is a hopeless soup of complicated syntax and lousy pedagogy. It’s aimed at beginners but really anyone who’s read chapter 6 of the book where he seeks to teach ‘what programming is actually about” using a calculator program as an illustrative example, he really makes it appear as if recursion is some exotic and esoteric thing, whereas it is a recurrent theme in the domain of programming. I say this because before this chapter he never used recursion and it becomes very unintuitive, unlike SICP, where from the beginning this is identified as one of the central ideas in all programming.
I was fortunate I used to read e-books and didn’t spend too much on purchasing flimsy books, turns out, as far as CS is concerned, the best stuff is actually free (and accessible as pointed above in the link)
That's something being a good, skilled programmer working on larger systems needs to be able to do. That's not something every programmer needs to be able to do.
Disagree, entirely. Knowing how a computer works is important when programming a computer. Just because you're not writing assembly when making a website doesn't mean you're not employing knowledge about a computer.
My list wasn't comprehensive, but I think it is a reasonably fundamental set. Without those "soft skills", the developer will not be great.
On the other hand, if someone has most of my list, then they are probably quite capable of learning the more specific things that meet your requirements.
What strikes me the most is that over long time I developed a crazy notion, which is a kind of build up of frustration I guess, which can be expressed with following words "this should have been solved by now, and it should be simple, darn it is 2021 century..." I do not know how many times I wanted to do some functionality, and then I would realize it is not implemented.
Regardless of what my expectations are for some language or library, simply it is not there, so after banging my head and burning hours trying to solve a problem I would realize I need to use some dirty workaround (and I hate those so much I do not have enough words to describe...)
Just a few example from JS world:
- parser that is simple
- jest framework working fast
- universal planet wide date time
- SCSS compiler that does not require C++ ...
- multipart/form-data request which can be interrupted in nodejs
- ...
For each of above there is some solution, but it looks like a dirty hack ... it seems with time, instead simplifying things we are complicating things that should be simple.
The other day I was pondering, how in any other trade people becoming masters, as they becoming good with their tools, tools are becoming part of their body, so they are focusing more on art and creativity, in programming, except for those rare who are blessed with very good and fast memory, tools are always changing ... as soon as you become comfortable there will be new set of tools... and I should not even start with the whac-a-mole of method and property renaming ...
If the points you brought up were simple, it is much more likely they would already be solved. The problem with these things listed is there is a massive amount of complexity in the edge cases.
That may be true, but I also find that too many things get "rebuilt" instead of "completed".
Rust is currently suffering from this in its libraries to a very great degree. Take XML for instance--the Rust alternatives are all missing quite a few features, but so is the wrapper for libxml2.
So, what do you choose when you need one of those missing features? You can 1) try to add it to the Rust libraries, 2) try to add it to the wrapper, or 3) just wrap the C library yourself with the features you need.
I find myself using Choice 3 (which I'm grateful I can do in Rust) more and more because I'm tired of incomplete Rust libraries that look like they do what I want until I start hitting those "corner cases".
Yeah this is probably related to the 80/20 rule. I do it myself. I get 80% of the way through a project in 20% of the time, see the finish line and what is between it and myself, and kind of check out unless there's someone pushing me.
It makes sense that people see a library, notice the problems, start their own - then stop at the hard stuff. And people like yourself who might have the talent to fix it will also have the talent to work around it in much less time with far higher reliability by reusing something else.
When you building custom application, you are trying to do it in most optimal way for the $ paid. So, when you building something for the value $ let say 100 SP (story points), and then when you stumble on a problem in OS usually you do not end up building 100000 SP side projects (worth $$$$$$$ of your time) in order to complete 100 SP project. Especially when you crossing to someone else domain.
Everyone has its own domain, so if Google, FB, Oracle, Microsoft have the main code base for Java, C#, JavaScript, React, Angular ... or else, it is expectation that they will listen cries of users, sometimes they do other times they do not.
Few years back I was involved in Google Chrome thread about auto-fill feature, at the time I was working at the health organisation, so to cut the long story short auto-fill was populating data and causing issue, in the very long thread I gave number of cases why is automatic form fill bad (and I was proposing some one-click alternatives), at the end Chrome team was sticking with what they wanted, and justification was "Because we are Google team, and you are not, so what ever we say is the best" - end of the story.
The premise of this article is that people say, "programming is easy," when they mean, "programming is accessible," or that anyone can do it with a will and a way.
This is true. What is meant when people generally say, "programming is hard," is that only some especially gifted people have a special talent they are born with to truly master it.
That's complete non-sense. It's the same kind of thinking that leads people to believe that programmers cannot possibly understand the deep complexities of product design, management, or any other skills a human could possess. It pigeon-holes people into a narrow vacuum of skill.
Yes, the skill of programming is technically difficult. I know many programmers, myself included, could probably write a passable implementation of binary search. But I know a good number of our solutions, when verified formally, will have errors in them.
What most people refer to as "gatekeeping," is this idea that some of us are born programmers and others... should not hold up hope that they can learn the skill.
Programming is a skill that is a commodity. The art of it is in being able to think, critically and solve problems using it.
I do think that at least as of today, programming (at the level of doing so professionally working on a shared codebase along with 50+ other programmers, not making a mess of things, and doing so 4+ hours a day every day), does require a level of attention-to-detail, abstract thinking, patience, and fitting-concepts-in-the-mind that much of the population doesn't have the aptitude for.
I believe everyone who wants to train enough to program professionally can do so, but many wouldn't enjoy it. Talking to machines is really unforgiving.
It is getting easier over time though so the barriers to entry are lowering.
Yeah, I think there is a general problem (that is, not just with programming) with the word "hard" being used for both "requires unique talent" and "requires hard work". Like, I would say math and physics and pretty much every other subject are "hard" too, but I think most people can learn them if they are willing to put in the work.
The metaphor I've been using lately is that programming is like art. Anyone can doodle, it doesn't have to be anything more than a line on a page. But to paint a masterpiece, you're probably going to need to know the inner workings of some language. We don't spend enough time talking about the correlation between programming and the arts. The metaphor is extendable to all arts, like music - symphonies, harmonization, cadence etc. I think if we emphasize this more, we'd find another opening for people to go deeper than the doodle. I worry about lack of access to the arts, it degrades the opportunity for deeper and more meaningful computer programming for future generations.
I've always considered it more related to craftsmanship, like woodworking, etc. Admittedly, that is also an art form, but of a specific type. Anyone can figure out / learn how to build a table. But it takes a lot more to build a _good_ table or, better yet, one that will last for a long time, or one that will best suit the needs of the person it's for, etc.
The skill set includes knowing what the different pieces you can use are (dove tail vs other corner connectors, etc), taking the time to plan out what pieces would be best, etc.
The metaphor goes further than that - you're not being paid to paint a masterpiece, you're being paid to be part of a 5 person team repainting the sistine chapel. That again is a totally different skillset.
It's important to take pride in your work but also to have a crystal clear image of what that work is supposed to be. Mistaking an apartment renovation for building the Burj Khalifa is the source of so much heartache.
Software as art is the most apt analogy I have encountered so far.
If you want to build nuclear reactors, sky scrapers or semiconductor manufacturing lines, go to college for 4+ years and follow the traditional paths.
If you want to compose a symphony or non-trivial software, skip the college and go sit in front of your instrument(s) for as long as you can stand to every day.
To call programming "Software Engineering" and building coursework around that term would be similar to developing coursework around "Music Engineering". The rigor of science/engineering (while certainly at the foundations of everything) distracts from higher-order and more human understanding once you get past the basics.
The entire game with software is managing complexity in a way that is sustainable for the participants. Effectively, this is what art seeks to accomplish as well. Capturing many raw emotions/ideas and integrating them into a single solution.
Funny thing, that is literally what I was told about drawing realistically - anyone healthy can learn to draw realistically. These days, there is whole pedagogy on how to do it, you "just" have to work hard and follow instruction.
There are absolutely people out there simply playing the diversity card to get attention. If you are pro-diversity, this shouldn't be something you want to deny exists, it should be something you want to prevent from happening, because it dilutes your interests.
It has nothing to do with the merits of diversity, it has to do with the fact that anything valued by society will have the signal forged by hucksters. Literally anything.
Diversity speakers are by far not the only ones who "oversell their own skills". Nor are they they worst oversellers I have seen.
And by that I mean that overselling own skills is incredibly frequent in this field and basically requirement in a lot of sub-cultures. It is just so incredibly common to read two tutorials and then claim yourself expert. It is not like consultants trading in impressions were rare or great expert developer comming in just for us to find we know more or something like that was rare.
But typically, they dont use beginner card nor diversity card, they are guys who do their best to conform to every stereotype of great programmer who play "I am expert" card.
I also helped start https://www.missionbit.org/, donate + volunteer with orgs like Black Girls Code, Code2040, etc. Phrases like "the diversity card" serve no rational purposes other than to discourage folks who already see programming as "something for other people".
And yes, I can imagine someone replying: "If someone is discouraged by _that_ then they're going to be in for a rude awakening once them start programming." Now imagine me wondering whether that person is more interested in winning a debate or learning about the actual circumstances and perspectives of their potential students.
Programming _is_ hard. It's also one of the few careers that consistently give people power and autonomy over the trajectory of their lives.
Either the OP wants that world or he doesn't. If he doesn't, fine, say and do whatever. If he does, then he should recognize that phrases like "the diversity card" have 100% downside.
Personally, I'll chalk it up to the OP being Romanian and using words/phrases whose sense is hard to get without being in the US or Canada (maybe UK/AUS/NZ too). For example, he says:
> I’m the gatekeeper now.
Maybe he means it in the sense that most folks in the US tech world mean it, but it doesn't seem like it. The OP seems to care about beginners being more discouraged because they were led to believe programming would be easier than it was.
But the words and phrases he uses signal that he wants to make the environment inhospitable to "casuals".
It's the difference between semantics and pragmatics.
Well, he may not have put it exactly right, but the term "gatekeeping" is often (maybe not always, but a lot of the time) applied in the context of diversity or the lack thereof: you're claiming that programming is hard and are therefore engaging in gatekeeping which contributes to the lack of diversity (or so the argument always goes). It's worth bringing up in this post because claiming that programming is easier than it is hurts everybody who attempts it, whether they're diverse or not.
I'm trying to give the author the benefit of the doubt. The tone of the piece has a definite "buzz off, newbie, unless you're ready to go HARD CORE" tone to it. He might not realize that because he's not a native English speaker and isn't swimming around in North American culture.
Maybe that was his intention, maybe it wasn't. Maybe he thought he was just "telling it like it is".
Maybe you disagree that the article has that tone. If so, I'd politely suggest that the way the tone presents to someone used to "programming culture" might be different than it presents to someone outside, someone unsure about their place in that culture.
Let me put it this way. I spent a lot of my time and energy finding people of all ages and backgrounds who have decided that programming is for other people and convincing them it doesn't have to be. This article makes my job harder.
Compare it to this:
> Some people will tell you programming is easy, other people will tell you programming is hard. Most of the time that's a reflection of how they felt or how they think other people should feel, not how it will feel for you.
> Forget easy or hard. Will it take a lot of effort to become really good? Yes. The question is whether that effort is worth it for you. The only way you'll find out is if you give it a shot.
> With the right effort, you _will_ learn to program. It can be for you if you want it. Let's figure out together whether this is exciting for you. If it is and you put in the work, I'll be there to help you go farther than you thought possible.
None of this "gatekeeper" or "diversity card" nonsense. Talk to the person as a person. Don't talk about your favorite abstract bugaboos as it relates to that person.
Yeah it is a bit sus to mention that in passing. As if it's yet another way these vily newbies nestles their way into the inner sanctum. Someone "playing the diversity card" is a massively positive thing for the industry in the long run, and should be encouraged.
Mostly everybody can learn to cook, only a few will become professionals, and fewer still will ever get a Michelin star. Mostly everybody can learn how to cycle, but only a few will compete in (let alone win) the Tour de France. Everybody can learn how to read and write, but there's only a handful of Shakespeares and Hemingways among us.
All of these are useful, easy to acquire, everyday skills that can be done at incredibly high levels of sophistication. Programming is easy in exactly the same way all of these things are easy, and hard in the same way all these things are hard.
Yesterday my wife asked me how can I work with music playing, doesn't that distract me? My response was my work boils down to figuring out what to make, then making it. The figuring out part is hard, and requires silent concentration. The making part is usually straightforward and music helps me crank along.
I find that playing music occupies the part of my brain that is easily distracted. This allows the productive part of my brain to work without distractions.
Without music, the easily distracted part of my brain starts looking for distractions, which drags the productive part of my brain along with it.
Music gives me momentum and puts me in the moment. In my most productive streaks I listen to music. Then silence is good when evaluating what I’ve done, cleaning up here and there and some refactoring. It’s come kind of call to arms if I needed to make an analogy even though Im not a fan of warfare
I like your observation. I've recently said similar things like "writing code is 99% figuring out what the hell this thing should do, and 1% is actually making it do that thing".
None or low entry barriers are an issue in lots of places. Even making a proper coffee is a craft you can't aquire just by googling around in a rainy evening (throwing hot water on pre-ground beans does not qualify you as a barista). Difference is you can only damage a coffee for the moment, not a whole software suite for many years to come.
Author touches a number of things but two messages resonate loudly:
- accessible != easy
- having the hard work done for you != easy
The “easy” myth was largely started by bootcamps trying to make an easy buck (NPI). More power to them, because clearly a lot of graduates were happy with their program and the career it unlocked.
But working on hard problems- often the foundational pieces that make the “easy” stuff easy - is a different ball game.
I spent the last 15 years of my career as an engineering manager type role, and the people who shone the most were the physics PhDs, electrical engineers, mathematicians that had changed careers, and the people who had for example worked on early home computing (where your computer crashed multiple times a day).
We made it a point not to hire from bootcamps and rarely new grads - not because of gatekeeping, but we had much more success paying 50-100% more for a hard science candidate.
> Most beginners in programming eventually end up with the same ingratiating message: "Programming is easy, everyone can do it"
This was not the message when I started programming. The message was much closer to it being something that is only for extremely smart and dedicated nerds. The message has been conscientiously shifted through dedicated messaging campaigns, for better or worse.
As I learned to program, I thought the message at the time seemed wrong, that it seemed easier than the conventional wisdom suggested. But during school, that developing opinion was tempered by experiences I had working in groups with or tutoring people, some of whom just never seemed to get it; they were smart people and could understand the answer once arrived at, but never seemed able to independently get to the next answer. Some of these people are very successful with doctorates in other technical fields, but still really don't get programming.
So my conclusion is that programming is neither uniquely hard nor at all easy, but definitely has some interaction with how individual people are wired to think and learn. This doesn't lend itself to nice slogans in an ad campaign though.
The other thing is that we don't need millions of gourmet chefs who can invent their own five-star menus. We need line chefs, and kitchen staff, and even burger flippers. Right now there's so much demand that even the digital burger-flippers get paid a good wage. So why does the OP feel the need to - yes - gatekeep people from the entire field?
Because right now there's no distinction between the burger-flipper and the master chef and moreover the burger-flippers are insisting that there shouldn't be one, even though there's an obvious gap in depth of expertise. The market supports paying both roughly the same right now but as more and more burger-flippers flock to the industry, the distinction will become more and more clear and the industry will bifurcate.
Okay, but the issue you describe is one where perhaps employers need to do a better job interviewing candidates for different tiers of roles. "Seniority inflation" definitely happens when it comes to job titles (I don't think it's a huge problem, but it probably isn't good), and people of widely varying skill levels definitely get put in the same levels of roles due to flawed hiring processes.
But the issue is not bootcamps, or StackOverflow, or "positivity" about whether or not individuals can be programmers at all.
I'm currently teaching python to some students on a conversion course who needed a bit of extra help. The most demoralizing thing for them is to keep hearing how easy python is supposed to be.
I had to flip that around from day 1. Python is not "easy". It's just "easier" than, say, C, assuming you already know C and the fundamentals of memory and stuff. If you don't, Python might even be HARDER to learn, because it automates a lot of that intuition about objects and memory away from you.
So you're not struggling because it's easy. You're struggling because it's hard! Like all programming. But also rewarding. Start from the basics, try to get a deep understanding as you go, stick at it, and you'll experience the rewards sooner than you think.
Granted, BASIC (yes the kind in all caps with line numbers) was my first language. So I'm biased, and mentally mutilated. Still, BASIC had something like a dozen important keywords, and you could at least offer a hand-wavy explanation of what the computer was doing with each statement. If you found a program in a magazine, it didn't do much more than what you learned in class, because there wasn't much more. And even specialized commands like POKE were not too hard to explain.
It was possible to walk through a short program and "think like the machine" to understand what it did. Frankly, even the GOTO was helpful in that aspect. There was no mystery about what GOTO did.
Today, Python is my main language and I'm quite productive with it. But I can't tell you with a straight face what a statement like x=3 actually does. In fact, to help people with Python, I'm more likely to revert to an explanation that is like what BASIC does with LET X=3. So I have to fictionalize or abstract away the computer to a greater extent.
Yeah, I'm teaching python too and it's important not to lie and pretend it's easy. I do try to emphasize to my student that it's a difficult skill akin to learning how to read and help them see each small step and how they build. I encourage my students by telling them that if they really want to do it, it is possible to learn these skills, and explain how it can be rewarding. I think it's important to let them assess based on reward vs how difficult they find it, so they have an honest view of whether to keep going or pivot to something that might give more bang for their buck.
As a programmer, please first define the words "programming" and "easy" ;)
If you instead talk about whole process of everything involved, then split it up into 50 distinct skills that all come together to 'imagine, design, mock, develop, run and support production ready software'.
To most people some of the needed skills are 'easy' and others are 'hard'.
For example just writing 'compileable code' with the help of stackoverflow is probably easy for most. That's not what i call 'programming' but pure beginners might.
> As a programmer, please first define the words "programming" and "easy"
I came her to say pretty much the same thing.
As far as I'm concerned, "programming" is just the art of writing instructions. For software developers, that means writing instructions for computers in a machine-readable language. But really any form of recording instructions is "programming", regardless of who the instructions are meant for.
I've taught my wife a little programming and for her the hard part is understanding how to translate instructions into a machine-readable language. Her biggest struggle is understanding how to decompose each step until it can be accomplished using the limited features and tools provided by the language.
When I think back on my education, we really didn't talk very much about the process of logically decomposing instructions. I've also had a hard time finding any resources to help me better explain the process to her. I wouldn't be surprised if that hurdle is responsible for most people giving up on programming.
I'm personally convinced that programming is _no different_ from any other skilled job. It's just that it's less tangible and therefore easier to misunderstand and harder to communicate.
I've been doing some deck building at my house and I realised that it's exactly like programming. I'm just some schlub who thinks, "I know saw. I know wood. I know screws. I can do this!" And then I discover:
- I can do this fast, and it'll look like a deck, and work, but not live long, and have a lot of really ugly things that don't quite work.
- I can do it really slow, and patiently, and make a lot of mistakes, waste material, time, and end up with a wonderful deck and a TON of lessons learned.
- I can get an expert team to do it in a weekend, using all the same tools and materials as I would, but because they've done it 100 times before they look like absolute wizards.
- And I can get a team to do it very poorly too, if I cheap out and don't hire the right people.
I have issues with the tweet quoted in the article. It implies that “anyone can code” and “coding isn’t hard” are false statements (and the article appears to agree).
First, I believe “anyone can code” is true (and generally anyone can do pretty much anything, barring obvious physical incompatibilities it’s only the matter of motivation). Second, “coding isn’t hard” is meaningless, as the verb “to code” is extremely vague.
That said, understanding different subject domains is hard, and good software architecture is hard. However, the mantra repeated by startup incubators like YC applies: to paraphrase, we achieve great things because we are ignorant of how hard it would turn out to be. (I sure was ignorant when starting out as a self-taught software engineer a decade ago, and I appreciate that back then no one warned me about how difficult various aspects of it are.)
I like the experience of teaching and helping (though not through selling paid courses or anything like that), it helps me understand the fundamentals better myself. When I do that, I don’t tell people that “coding is easy”—but I might say something along the lines of “don’t mind how confusing this process looks now; with good help it’s realistic for you in N months to get to a level where you can honestly earn US$15+ per hour (I will hire you myself if no one else does, as I routinely need help) and are able to continue to study by yourself”.
Is it possible that programming is both hard and easy? I somewhat feel that this post lacks the nuance that it complains of the other side lacking.
I'm of the opinion that anyone that thinks you must be of some special intelligence to become a software engineer is wrong because frankly it's no harder than many other careers. However, I do side with the author that we shouldn't be dismissive and pretend it's extra easy either.
I want some nuance. As with all things, programming is easy to get into, hard to be great at. Doing it doesn't make you particularly special. Working hard and getting better at _something_ is what matters.
I think the real problem is the word "Programming" is such a poorly defined and generic term. Until you pin down exactly which definition of programming you are talking about saying "Programming is hard" is no more meaningful than saying "Mathematics is hard" or "Writing is hard".
What frustrates me is the reputation programming has, it has somehow cultivated this image that computer code is some kind of magical and esoteric thing which you need to be some kind of genius or wizard to understand. It's reputation is such that otherwise sensible people will balk, hesitate and just completely shutdown when confronted with code. I am an engineer (the non-software type) I see this behavior in my coworkers and it frustrates me to no end there is this prevalent attitude 'I'm not a programmer, computer code is too hard to understand...'
It reminds me of the reputation Mathematics (the subject) had when I was in high school. Math had a reputation as being a 'hard' subject so a lot of people seemed to come into it with preconceived notions that it was difficult to learn and therefore they weren't smart enough to understand it so they weren't going to engage with it. I see exactly the same attitudes with 'programming' today.
I think programming is easy to get into if it's just something you enjoy (which could apply to anything, really). Throughout getting my CS degree it seemed like there was a pretty clear line between the people were going through the motions of the courses and making it through based on what was taught and the information provided, and the people who just enjoy programming and do it for fun in their free time. If you're the latter, you'll probably naturally pick up the required skills cause you're engaged and want to learn more.
While reading this article I thought about bootcamps who usually spin these kind of narratives.
I never really found reliable numbers for what percentage of bootcamp graduates actually get a job as a software developer. Their marketing mostly talks about anecdotes and a lot of bootcamps have a very strict application process so in a way they act as gatekeepers as well (not to mention that not everyone can afford them).
Displaying <? echo "hello world;" ?> is programming, doing some Excel thingies is programming, heck, even doing a
> print 'test'
inside the Python REPL is programming, all this is not that complicated The only issue is that we've stopped calling that sort of stuff "programming", we've started moving the goalposts more and more, and then of course "programming" has become harder and harder: if you don't write tests you're not programming, if you don't to TDD you're not programming, if you're not ready for pair-programming you're not programming, if you're not writing everything inside a container you're not programming etc.
That's a bit of a crude reduction, in my opinion. If we are debating semantics, then I would argue that I'm a part-time surgeon because I removed a splinter. I would do more surgery if it wasn't for all the civil engineering I've been getting up to in the garden lately.
Sure, surgeons and engineers have to start somewhere just like programmers. But they also have well-defined gates to make sure true imposters don't get in.
Being a surgeon is not the same thing as being an engineer, being an engineer is not the same thing as being a programmer. The post was about being a programmer, i.e. about making computers “automatically” do the stuff that you want them to do.
"The group found that pass rates in introductory programming courses appear to average about 75%; that there is some evidence that they sit at the low end of the range of pass rates in introductory STEM courses; and that pass rates both in introductory programming and in other introductory STEM courses appear to have remained fairly stable over the past five years. All of these findings must be regarded with some caution, for reasons that are explained in the paper"
I wonder if it matters that in virtually every other STEM field, students in the intro course have already had a year of the subject in high school. In math, they've had several years, and at most colleges, they take a placement exam before they're allowed to take calculus as freshmen.
The article has a good message overall but I think this title works against it. A much younger and more impressionable version of myself heard Marco Arment on a podcast around 2010 saying how difficult iOS programming was, and I kind of believed him at face value. It was 9 years before I gave iOS/macOS programming another shot, and I was more productive than I'd been in any other programming language. I agree with the article that telling people programming is "easy" is probably not a good idea either.
Having written for both platforms at the time, I don't know about 2010 but by around 2011 or 2012 it was sure as shit easier to program for than Android. By a long shot. And a breeze to maintain an actively-developed app in the field, by comparison. Maybe there were also-ran mobile platforms that were easier, or not-apples-to-apples comparisons with, say, desktop development, where that's easier, but if you wanted native mobile dev Apple was a piece of cake (pie?) compared to its main competition.
[Edit: Nb my perspective is that of someone who'd never used a Mac full-time before working in mobile development, had never even looked at Obj. C before, was quite familiar with Linux and to some extent Windows, and had a passing familiarity with Java, so if anything my background should have biased me toward Android, slightly. Last time I touched native on the two platforms was, oh, 2017 maybe, and it was still true.]
Not only did the language change significantly in 9 years, your skills as a programmer likely did as well. How can you evaluate the truth of the original statement given these factors?
I'm saying it turned me off to iOS programming b/c it made it feel out of reach, regardless of whether it was true or not. Regardless of language, when you list all the reasons it is difficult to program (the things you may have spent years getting past/overcoming) it's going to turn new people away from it
While it is true that there are lot of resources for people getting started and getting into programming, and that "Beginners walk a very fertile ground," I think that misses the point. Something about our industry and trade has been exclusionary. Perhaps unintentionally. The "anyone can program" movement seems to me to be in large about about addressing this - you don't have to be a particular gender or ethnicity to write code (either just for fun, or for a living).
It is true, as the article points out, that programming is hard. But we teach lots of things in school that are hard that no one will do professionally. Calculus is hard too, but more people take AP Calculus in the US (based on https://secure-media.collegeboard.org/digitalServices/pdf/re..., around 400k) than take AP Computer Science (based on same, around 188k). I don't think Calculus is that much more valuable, nor is Computer Science that much harder, to justify such a large gap. The point is, even among STEM subject, there's a taboo around computer science and programming.
But it is equally true that it's not helpful to tell people that programming is a walk in the park, and the article does a good job explaining that. Perhaps better than saying "programming is hard," or "programming is easy," we say "programming is worth it" and leave it there.
> The point is, even among STEM subject, there's a taboo around computer science and programming.
I really thought this was no longer true, but it rings true to me as someone who was in school in the 1980s and 1990s. Back then, being into computers was a social liability. It was way worse than being into math and science. Math and science weren't optional, and they were important for college admissions, so being good at them didn't prove you were a weirdo who actually liked that stuff. You were just taking advantage of your intelligence to succeed at something that everybody else wished they were better at, too. (Assuming, of course, you didn't cop to thinking calculus was SUPER COOL.)
Being good with computers, on the other hand, demonstrated a kind of stupidity that outweighed the intelligence it required.
To understand how it could be socially negative to do something that everybody assumed required a lot of intelligence, you could, from a narrow point of view, compare being good with computers to going to jail for beating up a police officer. Being strong and tough was a desirable attribute, just like intelligence was, but that particular way of proving it was way worse than not being strong at all. It showed a different kind of weakness that cemented your identity as a loser, somebody that a "good" person was better off not knowing. Even if it made you seem mysterious and fearful, at the same time, it made you "less than" and socially irrelevant.
I thought this was changing in the 21st century. When I look at people under 35 in the industry, I don't see signs of having grown up under that social stigma. I might be missing it because of other generational differences, though. I'm curious what others think.
> Perhaps better than saying "programming is hard," or "programming is easy," we say "programming is worth it" and leave it there.
Maybe "programming is necessary" or "programming is ubiquitous?" Maybe the best way to remove the stigma is to convince kids that people who struggle with programming will wish they were better at it, rather than being able to dodge it entirely. Let's turn it into something that everybody wishes they were a little bit better at, so they don't automatically look down on people who succeed with it.
I took both AP Calculus, AP Computer Science A/CSP. CSA has you work with miniscule Java problems while CSP had you do things like define "big data" and what IETF stands for. Despite getting a 4/5 on the exams, I don't feel like they resembled anything like my introductory classes at a state university, and don't really seem to apply to either the academic wing of computer science nor software engineering. I'm sure part of that is likely due to teaching, as I preferred my highschool math teachers to the technology/computing teachers, but the curriculum seems misfocused at best.
20 years experienced self taught Dev here. And still learning.
The best analogy I can get with programming is to compare it with lawyers.
It takes 7 years to become a lawyer's, and it takes about the same to become a senior programmer.( Assuming 7 years of work experience with a mentor ).
Now, lawyers all have a field, family laws, international laws, constitutional laws, corporate laws. Ask a lawyer who did all his career in corporate law to have a go at a divorce hearing... He will be miserable, and fail.
Programming is similar. You can hear a good lawyer talk and win a case, and it looks easy. But it's not easy.
How many case did he lost before, how many failures.... And now many hours of study did he spent to make sure the argument is a winner?
And where I resonated with in this blog post, is the arrogance and the entitlement of some of those junior programmer, specially in the front-end web industry, who claim to be senior.
I once worked with a 22yo kid who was paid as much as I did, and couldn't write a loop.... He was just a good talker and negociator. 1000$/day to write CSS is really a failure from recruiters and the whole business in general. When juniors think they are senior, they usually take the lead, and the projects goes direction 'fucked'.
And now being good at programming also means being able to get rid of those parasites , which is not eqsy- as their capacity to argue and convince is inversely proportional to their capacity to deliver quality working code.
Programming was the first “hard” class I took in high school.I did miserably in it, barely scraped by with a C. Despite having a ton of interest in it and a desire to learn, it was just so hard to get started. I decided it wasn’t for me and studied something unrelated in college. I took a dead end job out of college because I had no idea what to do with my degree.
I randomly met some professional software engineers through a local run club and started doing online classes/coding challenges with them through edX and project Euler. The spark came back and I decided to entertain the possibility of doing this full time. I made the leap and have been quite happy with my decision.
I think I was put off because I struggled so much with programming compared to my other classes. I didn’t see other people struggling with it, because the smart kids were the only ones getting called on. In hindsight, most of the class was struggling and I fell somewhere in the middle.
I like the idea of explicitly saying programming is hard. But it’s double edged, it will put off many people who may have an aptitude for it because most beginners are full of self doubt and humility. To the authors point, we should work towards changing the connotation around the word “hard” to be more positive.
My thoughts...
It's interesting that popular(ish) Twitter people that are part of #100daystocode (e.g. Cat McGee ) have shown up here on hacker news. It seems like 1000s and 1000s are part of this twitter movement. There is good and bad with it.
Cat McGee and her ilk, to simplify, are selling programming as a lifestyle. It's not the coding that's the point- it's the opportunities it gives in terms of good jobs, ability to live in foreign countries etc. And they gush over how programming is in fact easy.
I can definitely see how programmers might feel uneasy about this trend of tons of people being interested in getting into the industry. Obviously, at some point certain areas are going to be put under a lot of pressure. Potentially.
As the above author notes it's a lot harder to work on a fully functioning 100k line webapp/software than a toy website. And from what I see on twitter, most of the drive is on html/CSS/JavaScript learning.
But in other ways it's a good thing. Even if you are not a developer - writing code can be a real joy as a hobby. And a bit of coding skills can help people in non-coding jobs. Or just to create some thing small. (disclaimer I'm a data analyst trying to become a data engineer). And the Twitter groups like #100daystocode do expose more people to the fun side of coding. Let's face it most high schools fail at that.
On a final point, like writing a novel/script (a demon I know all too well.) there is a dream bring sold that you can live in an exotic location and work remotely. Its more of a realistic dream than writing to be paid, but still people might need to be careful about fools gold.
I think the authors point is generally valid. But...
Personally, I see things as 'programming can be easy or hard (but doable), but only if you have the type of mentality that you will never quit.'
Basically anyone can learn a language if they are exposed to it constantly, and if you are programming or debugging a lot, it is inevitable that you will learn the language you are looking at. And basically everyone could get to that point. They could also learn to communicate basics with their language. But it obviously doesn't mean you can build a rocket just because you have the ability to read language and books related to rockets.
So I think there are some easy things about programming that do apply to 'everyone', and for those things it may be appropriate to say 'anyone can do it'. However, there are certain things that require deep understanding of complex subjects generally only learned by hard work. If you are not the type of person who likes to work hard to learn, then you "can't" do those kinds of programming tasks.
So it is both easy and hard, depending on your mentality. What parts of it are easy and what parts are hard may vary based on aptitude and a variety of other factors.
When I taught programming at a coding bootcamp, my first piece of advice to students was always “Programming can be hard, so it’s important to have fun”. We would start by creating ascii art in the console, and move into slightly more complicated graphics to become familiar with loops and control flow.
Being able to marvel at the magic of code can get people through those grueling moments where nothing works and the answer isn’t on StackOverflow.
Programming is easy if you have the particular kind of brain that is organized in the way that programming demands. If you can visualize structure and remember trivia and pattern match on things, it's not that hard.
A lot of people can't do those things, and they struggle mightily; in some cases they simply cannot do it. Might as well try to be a musician if you are completely tone-deaf.
Maybe "programming is easy" as a motto should be seen like "anyone can cook" in "Ratatouille": Not that programming (or cooking) per se is easy, but that it should be seen as open to practitioners from a wide range of backgrounds and preexisting knowledge.
However, like cooking, programming requires years of dedication, experience, and experimentation to master.
“Easy” and “hard” are really only meaningful on a relative scale.
While I think the author individually makes some decent points, I would normally disagree with the top-line “programming is hard” message, and the further implication that “programming-is-hard” gatekeeping is a positive. (OTOH, its worth noting that much of the opposition to the gatekeeping is capital interests trying to increase supply to drive down labor costs, and much of thr gatekeeping is the reverse from incumbents—and must especially the last skilled, most at-risk from expansion of skilled labor supply segment of incumbents—and has nothing to do with the merits of the arguments.)
OTOH, on a scale where “using the right quotation marks for the language you are writing in” is prohibitively difficult, I’d agree that “programming is”, at least, “hard”.
This triggered me. Senior is a title that, like everything else in our Agile world, has been evolving to subsume activities that were once considered to be more specialized. Similar to how "devops" has combined sys admins and network engineers with development, and agile itself has combined "business analyst" with development, Senior now includes "team lead" and "architect". It's a pitiful state of affairs imo.
And we've done it to ourselves. Every time we as a collective have complained that X is a waste of time, this persons job has no value, we don't need them, guess what? The people in charge listened. I personally don't like that this has happened for the primary reason it makes my job harder.
"Junior" means you implement designs prepared by someone else. "Senior" means you are the one making the technical designs, to be implemented either by yourself or by someone in your team.
In these definitions, "design" refers to the overall structure of a program or system. The level where decisions like "do we hit the DB for every query or put a cache in between" are made.
These separations are completely arbitrary in practice. I've seen many seniors not doing any technical designs, and I've seen many juniors expected to stand on their own two feet when it comes to making technical designs, sometimes to the point of requiring those skills before getting a job.
Reality is, the title means hardly anything anymore except "this person has this many YoE" and whatever value the company attaches to the title in a given context. That's what has made the title so watered down.
Additionally, many graduates can make technical designs. They won't be the best. They won't think of everything. They likely don't have the foresight to think of problems happening along the way. But they are being taught how to convert requirements into a working solution during school years. I have a hard time believing "seniority" is defined by a few years of practical experience in something that was taught in school.
They are usually meaningful within a given company and become increasingly important as the company grows in size. Comparing titles between companies is usually pointless.
Agree with the message, programming is really hard, and the earlier you realise it the better it is. Having “programmed” for the greater part of the last decade, starting out with ‘scientific computing’ in Fortran and matlab (I was doing chemical engineering), then spending precious time believing (and learning) that C and C++ are ‘the’ languages and having pop science ideas that Java is slow (‘it’s GC after all’), only to realise its much faster than C++ if you do ‘new’ a lot, I realised how less I knew about how hard programming really is. Just a glimpse of the hardships I went through. All this meandering was due to the belief that programming is easy (peddled around by legions of tech blogs and YT channels), and that there’s only a little more that CS students learn as part of UG degree curriculum.
Right now I am doing SICP and it’s giving me the essential ideas which all CS students learn but which hardly any programming blogs recommend to beginners. Learnt so much already (I am halfway though chapter 2), I now realise it was never about the language, it’s the ideas and techniques like recursion and FP that are the core of programming.
There’s no need to say that programming is easy, just tell people what they really need to do to be good programmers. And without a strong CS foundation it’s very hard.
Most things in programming are incredibly easy, at least the building blocks. Some algorithms and such might not be easy, but they're just different combinations of building blocks.
I think 95% of people just have not flexed their brain muscle hard enough (and often enough) to spend more than 15 minutes in intense focus trying to solve something without giving up or being consumed with self-critical thought. This is blindingly evident when trying to teach people (probably hundreds at this point over a decade) and very few manage to have intense focus without some completely self-sabotaging mechanism about their own worth, their own abilities, are they smart enough, etc.
This by far is the hugest inhibitor... on the small chances where I've found ways to move past this, people will pick up core concepts quite readily and easily, and exclaim "oh, so wait this really isn't that hard."
Things like rust data types or something might be "hard" but no one starts there. If you follow along the general path, you can have large accomplishments in learning/progress the entire way up the food chain over 10+ years and never once along the path is it really like "GOSH THIS IS HARD!"
Let me rephrase, programming is easy, software engineering is hard.
Scripting Word or your editor of choice is not particularly hard, writing a python script to read a csv and output some text is relatively easy.
Designing and implementing a large scale Web application with metric collection, real time reporting, multitude of data integrations, aggressive availability requirements and worked on by 10s of engineers across a number of teams is hard, real hard.
In college I helped a friend (very smart guy) with some of his intro to programming class assignments. He had the hardest time understanding very basic things. He would've struggled with a fizz-buzz type problem. In many other fields he is highly competent, but he could not grasp programming. I think people who know how to program don't realize that what they find easy is often extremely difficult for other people.
I expect we won’t see these kinds of debates in 50 years. But right now, we’re just recently getting past the stage where anyone who programmed a computer was a programmer.
You’d see the same thing if anyone who used a keyboard was called a “Writer.” You’d see hello world tutorials demonstrating that all you have to do is press these keys on your keyboard and they show up in your text editor! You can be a Typer! And then what we actually call lawyers would come in and say no, writing a good document requires a ton of work and prior knowledge. And others would say that doesn’t matter because I just need it to write work emails and that’s more typical of a Typing job. They’d argue because they’re all talking about the same job, kinda, and that lets them talk past each other. Vague terms make for discussions that go nowhere.
I hope in 50 years, being able to program hello world will be as universal as being able to type hello world, and the different parts of programming will have clear enough names that we can say the equivalent of: typing is easy, clear email communication takes some writing skill, and writing a good legal contract for your client is hard.
I would say that learning the basics of programming (if then for while functions classes structs etc) is easy and anyone can do it. Learning to think like a programmer is harder but also not super difficult IME.
Being a programmer. Doing it for a living. Getting good at the craft of programming and learning the foot guns and ins and outs of your chosen language/stack/framework. That’s hard. And time consuming.
Forget gatekeeping programming, I'm going to gatekeep gatekeeping programming. Contrary to what this article claims, the sentiment that "Not everyone can program" is well worn, especially on this forum.
I think the paradox of programming is that it's easy for some people to learn, and prohibitively difficult for others, and we don't know why. If you think something "special" makes it possible to learn programming, like high intelligence, math, abstract thinking, whatever, you will meet people who lack those things and are getting along just fine as programmers.
In my view, programming is easy, doing something useful with programming is as hard as the thing you're doing with it, such as software development. When programming is hard, it's because of the things that generally make hard things hard, in or out of programming: Complexity, domain knowledge, shifting technology landscape, organizational management, etc.
The thing that makes software development stand out is the degree of complexity that it allows for.
An indication that software development is hard, is the number of books and debates on trying to manage it.
Disclosure: I've been programming for 40+ years, but am not a software developer.
Programming is some combination of complex and difficult.
"Difficult" in the sense of mathematical elegance, algorithmic design, or other sense of academic "hard". Keep in mind the average developer probably doesn't understand big-O. Usually these programs/systems are focused on the specific algorithm and not a lot else.
"Complex" in the sense that the code may be no more than a glorified crud app in the classic database-transport-presentation architecture, but nevertheless has such a breadth of data, classes, types, frameworks, and the like that it still becomes "hard".
So a "casual" programmer will run into the hard-complex code structure, but will flounder completely at hard-difficult algorithm.
Of course SV/FAANG interview on hard-algorithm, and then make them spend all day on hard-complex crud.
The reality is that hard-algorithm requires academic smarts, but hard-crud requires social and management skills.
Well, to be fair, I don't think "Anyone can code" is an identical statement to "Programming is easy."
Programming involves having a purpose and understanding the architecture and so on. Writing code isn't, per se, about all that.
Kind of like saying "A five year old can learn to write." and someone having a cow about "A five year old cannot go from not knowing their alphabet to being an award-winning author overnight!" Well, okay, but that wasn't what was meant when someone said "Any five year old can learn to literally write."
Programming is more of a big picture thing and that fact is largely unrelated to the simple fact that, yes, if you wish to write code for some reason, you actually can just look stuff up online.
And I think for some people who are used to needing permission, socially, to do anything, it actually is a significant detail worth commenting on that You don't have to ask anyone or get permission to do the thing. You can just look stuff up and do the thing because you decided to do the thing.
I know a little HTML and CSS, but I don't self identify as a programmer. I am self taught and it's useful because I blog and it's helpful for that domain, but, no, I still can't, say, write an indie game (an actual goal of mine).
It is literally true that anyone can code by looking up stuff online and maybe for some people what they are kind of trying to say, to build on a metaphor used in this piece, is "You don't have to go talk to the head chef and fill out forms requisitioning eggs. Anyone can crack a couple of eggs and start cooking!"
Which doesn't in any way imply that cracking a couple of eggs and frying them up makes you the equivalent of a trained chef in terms of the quality of your work, the complexity you can handle and other pertinent stuff (such as ability to manage a staff in a commercial kitchen).
Interesting that the author didn't really discuss WHY programming is hard; I agree that it is, but if their concern is that beginners are being misled into thinking it's easy then I would have expected they'd spend some time exploring what programming is really like rather than commenting on tangential social issues.
My own experience as a programming teacher leads me to believe that one of the main difficulties for the new programmer is the level of precision with which they must be able to articulate a concept in code in order to have it work. For example, it was much more common for a given student to grasp, say, a conditional statement and when to use it than it was for them to understand that changing the capitalization of a variable meant they weren't referring to what they wanted.
Learning programming is no different than learning to become an artist, a musician, an engineer, a mathematician, an athlete, etc.
Those things are all hard if you want to master them, but not everyone needs to be a master. I can draw, get great joy out of it and benefit from it without being Rembrandt. I can use vector math to make games and not dedicate my life to mathematics. This is also true for programming.
You really don't need to be smart to be a programmer, but if you want to be good at it you need to be smart enough and tenacious. Programming is just a tool to solve problems in the modern world.
The book "The Outliers" was what gave me the confidence that I was smart enough to be a programmer and achieve great things. All it took was a positive mental adjustment. This article is rubbish.
Really good essay, that I've passed on to my college student (in simulation programming) children. There's real wisdom in there, no matter how long the author has been coding, there's no doubt some mileage has been racked up. I've been coding since the 70s (in the beginning there was _basic basic_), but have spent most of my tech career in system administration where most of my programming has been for utility scripts in various shells, perl and python. Still, because I've worked closely with developers over the decades, "programming is easy" is a falsehood I've experienced many times over -- and one I don't think is helpful at all (any more than "masks won't help you avoid being infected).
Programming is easy. Solving problems is hard. Working with people is hard. Learning the culture is hard. Remember to apply common sense is hard. Becoming a master in a easy craft is super hard. The last one requires you to figure out the zen that even masters cannot tell.
Most people commenting on human nature have no formal education in it. A good place to start is Steven Pinker's, "The Blank Slate, The Modern Denial of Human Nature." Claiming everyone should find something easy is a blank slate statement.
> We also have no clue of how to program within specs at scale.
We do, but no one wants to pay for it, outside of very few select industries with very high reliability requirements (space travel, medical devices, etc.).
> "We also have no clue of how to program within specs at scale. Basically every month we have a huge breach at a major company."
So many of these breaches are caused by absolutely boneheaded mistakes, some of which are known bad practices dating back to the '90s like allowing SQL injection, that I'd say that, no, we darned well do know how to do this. We are simply failing to hold developers (and their employers) accountable for knowing how.
That's less of a problem with building to spec (security is not a "spec") but instead with employees who are not familiar with keeping data safe, companies that give too much access to regular developers (e.g. Uber, I can attest), or engineers who are underqualified but charming or otherwise smooth talkers that worm their way into security-related positions when they have little to no experience or knowledge in that area.
> Programming is hard, programming is not for everyone, and for the time being everyone might be able to do it, but most definitely most should not
The same could be said for cooking, but I'm here to say that cooking is good and everyone who is interested should try it!
There's nothing wrong with canned software, but a bit of programming/algorithms can empower you in almost any discipline, particularly ones that have to deal with numbers or data, much as algebra and statistics can.
There's a reason we have Scipy, Octave, Matlab, Mathematica, R, SAS, Julia, etc. after all.
Not to mention that even Microsoft Office includes VBA, and every web browser includes JavaScript.
I could have written this rant. Excellent stuff :)
But, the thing is... programming is easy for some people. If your creative mind turns that way. Like "drawing is easy, anyone can do it", which is true provided you spend most of your waking life drawing. "Music is easy, anyone can do it" - again, true for some. Not for me, I'm almost tone deaf and have no sense of rhythm.
But programming is different from Software Development as a career, just like "drawing" is different from "commercial illustration". Being good (or successful) at Software Development doesn't necessary involve being good at programming.
Programming involves a spectrum of diverging skills and specialties, at the low end, it is relatively easy. I have seen people with very limited programming skills leverage what they know in spreadsheets, scripts, and other tools such that it makes them a lot more productive. Career programmers span a wide range of the spectrum, many leverage other domain specialties. I would say most deal with moderate problems where there are mostly known solutions and often it's a matter of having the skills and knowledge to craft something together that is appropriate for the task at hand, much more like engineering.
Probably, the best answer to the "programming is easy" mindset I've read is this article[1] about whether software engineering is actually engineering. Turns out we are engineers, and we're not even that special as far as engineering goes.
And it's funny, because the article has nothing to do with whether programming is hard or not. Not idea what Wayne thinks of the matter.
There are two main ways to think about "hard". One of them is "not many people can do this". The other is "not many people could do this".
When people disagree over whether something is hard, I think the disagreement usually comes down to semantic disagreement over these two definitions. Also, some people think we can get rid of the latter ("not many people could do this") because it's hard/impossible to prove. But I think both definitions are an important part of what we mean by hard, and we can't get rid of either.
Not much novelty in this concept is there? Tennis is easy. You can hit a ball with a racquet pretty easily, gettin it in is a little more difficult. But when you get to a much higher level, there is spin, footwork, eye hand coordination, endurance, wind, returning 130MPH serves -- hard stuff. At pro level, if you hit a ball with at an angle just a few degrees off, the opponent can use that as an easy winning shot. Things are easy and hard with different circumstances. I think this is a pretty generic statement that applies to many things.
No, but no one is going around making blanket statements (or in the case of the article, tweets) about how easy tennis is and how everyone can and should pursue it as a career path.
Getting into programming is easy. It only requires some baseline level of interest. There's no formal certification. You don't need specialized tools. With a laptop and an internet connection, you can be up and running making toy programs on day 1. How many other fields look like that?
On the other hand, creating and managing a large code-base is no mean feat. Making production code that does something people are willing to pay for usually takes time and effort.
And as usual, learning to program is one thing. Becoming good at it is quite another.
Programming can be pretty simple. Ofc, some tools(languages) are harder than others. What is hard is software development, software engineering and computer science...
Quite vastly different fields. And two of the first ones are needed for good software. And the last one if something novel is being done. What is hard is to be in some intersection of these and being able to deliver value.
Programming itself might just be implementing spec or gluing code together, skilled field, but could be done by tradesman...
I agree, programming can be hard when you have to solve new problems from scratch.
From my point of view, programming is a creative process, like writing, anybody can write, it's simple. But few are able to write a book, and very few are able to write a good one.
If you are relying on others code/libraries, you are not solving any problems, all the heavy lifting has been done for you, and you are only fillings the blanks and/or stitching multiple stories together to write the book.
My thoughts are that programming is easy. After all an average 8 year old can do it.
What is hard is modeling large, complex problems and systems in code, that meets its functional and non-functional requirements.
The superior “programmer” is one who can to some degree perform the latter. Of course few organizations have any way to quantify these superior skills, resulting in the rote textbook question and IQ interviews that today defines a “programmer”
It's not easy, it's just totally unregulated. Meaning it's easy to "be a programmer."
Want to be a real engineer? There's a professional body for that. Doctor, lawyer, electrician, etc.? Same. Not us programmers.
The big difference between us and them is liability. Nobody expects software to work. Thus nobody gets their pants sued off. Thus we don't need professional accreditation; we're not vetted.
I had two, mind you two, programming classes in high school in 1966-7. We wrote FORTRAN code and ran it on the high school’s 1130, with 32k of 32-bit RAM. Stuyvesant. Cold War and the space race environment.
Hopefully that level of interest and funding is returning. When the Chinese walk on the moon, that will be a wake-up.
programming is hard just like discovering a proof for a mathematical theorem is hard.
software engineering, that's a completely different level of hard. you have to be a good programmer just to begin to understand how to make actually good products, not just toy leetcode puzzles or write only run once scripts.
Everything is easy though, humans can learn, I don't really believe anyone is so removed from potential that they couldn't learn to do any job at the average level of the average job's practitioner.
Accessibility thus actually becomes the crucial differentiator. The opportunity to learn and be taught by the right people, to learn at the right pace and the right time, to be in a motivating environment, etc.
So I think what people mean is... Yes programming is accessible, and there is good job prospect, and if you are worried you're not smart enough, that's crap, everyone is smart enough, just give it a shot. All you need is to be interested enough to put in the time and effort. Now you might not be interested enough, but compared to a lot of other things, programming costs you nothing to try.
Same with mathematics, it's easy, but most people don't find it interesting enough to put in the time and effort. But mathematics is also less accessible, not as many blogs, free material isn't as available, there's no machine to freely assess you and grade your work, etc.
I don’t disagree with or dislike the article, but I feel the author could have included some examples of what he considers programming, and what he considers hard, as he listed quite extensively the things he doesn’t consider programming or hard.
Drawing and painting well are both hard. Cooking well and fast is hard. The difference between those skills and programming is that you don’t have people discouraging strangers from even attempting to acquire those skills.
You don't have to discourage strangers from programming either. It's just some people, like the otherwise quite intelligent author, feel the need to do so. Such discouragement seems ugly, mean-spirited and kind of despicable.
Programming in isolation is simple to learn. Rudimentary understanding of control flow, syntax and how to use primitive data types are literally enough to write any program in the world. I feel like 80% of people could probably go from zero to fizzbuzz in a week if they had a good teacher and a modicum of interest.
But the real world is so much more complicated and that it is the real gatekeeper. I've taught several non-technical people how to code, and the biggest first hurdles usually are: setting up their dev environment, installing dependencies, understanding the command line.
I think it's interesting that explaining why you have to add things to your $PATH is harder than explaining how an if statment works.
I've seen people try to do flow or visual programming. There is no barrier due to dev setup. They don't even have to understand the low-level details about how a computer actually works.
But despite that, they still have trouble getting anything to happen.
While not all smart people can program, professional programmers have an average IQ that is a full 24 points higher than average [0] That's one and a half standard deviations above the population average.
If you account for all the programmers you meet that seem incapable of doing anything, I suspect that the IQ of people who actually get things done skews even higher. Even if you buy into the whole "IQ doesn't measure everything" camp, the things it does measure (logic, pattern matching, memory, problem solving, etc) are exactly the same things that are critical for a career in programming. Based on this idea, it can be said quite simply that the overwhelming majority of the population are simply incapable of performing the job well.
Good point. It took me years to learn software well enough to be able to understand, fix, and anticipate those kinds of issues. Even now that I write software professionally it still happens at a more technical level (for example, I’ve been tripped up by esoteric aspects of how networking in data centers works).
Modern computer systems are just very very complicated which makes teaching them challenging: nobody, even very very good programmers, knows how all software works from top to bottom. So being productive writing software requires a self-starting, deductive approach to solving problems, which is much harder to teach than basic syntax.
Programming is moderately difficult for beginners. Learning the tools, syntax, idioms, libraries... it's a lot to swallow.
Programming is nothing compared to architecture though. Knowing what you want to build, in a way that meets the requirements, is a very time consuming task for all but the simplest of problems. Once you have that, and the aforementioned background in programming, the remaining work isn't very difficult.
If someone is doing the architecting for you and defining the work sufficiently, programming isn't hard. It's not easy, but it isn't hard.
This is very much in the right direction, but to expand on it a little with my 2c...
Programming something to produce an expected output is for the most part a very achievable goal when you have no constraints. You can do it however you want, take as long as you want and no-one else will complain how you do it.
The more layers of constraints you add in the more challenging it becomes to the point where you could say "programming well" is indeed very challenging and the majority of working devs can't achieve it reliably.
I think over time it's a fundamentally impossible task with respect to a certain piece of software because the trifecta of 1) changing industry/aging tech, 2) everyone who contributed to the codebase at a time they didn't understand the system, the domain or programming all that well, and 3) accumulating mistakes in architecture or implementation that you don't have or ever get the budget to fix.
So in the end even if you're a stellar dev, you're always working with people who aren't and most likely on a system that is not pristine.
Getting a computer to do _something_ is not so hard. Consistently getting the computer to do what you want over time in a way that is easy for your colleagues to grok such that they don't introduce mistakes and also to do it in such a way that's amenable to unforseen future requirements that may or may not arrive? It's ultra challenging.
I've learnt to not care so much. Software is an organic thing that will be born, grow, get old and die.
Many people in our industry never get to do much architecting beyond a very limited scale. Much of my career was spent fixing bugs as a contractor or implementing very targeted features in embedded systems. It was only later on in my career where the balance shifted to more architecting of larger features.
Plenty of folks are just 'programmers'. They're barely software 'engineers' and definitely not computer scientists. It is perfectly reasonable to spend your entire career as a programmer, dealing with small issues in a systems you inherited from someone else.
I don't think the GP is claiming they are separate fields. However, I would say they are separate modes of thinking and require different skill sets.
For example, software architecture around systems design might involve thinking of different layers of responsibility, the sequentiality of development, taking into account the skillsets of the teams and existing technical tools and structures.
To me, programming is the art of transforming and ascertaining requirements and principles into executable structure.
Architecture is the art of shaping the non-functional requirements and principles. Either by writing them down or by discussing them at a whiteboard, or even by teaching the team about these requirements.
Both are like an entangled pair that can be incorporated in one single individual, in different team members or even in different organisational structures. Some architectural decisions can be championed by a random software developer. Some architectural decisions shape companies (AWS). And some architectures should just be thrown out of the window.
But, and I am speaking from experience here, as they are different modes of thinking, there should be conscious time and effort for both and they should not be mixed indiscriminately.
I don’t remember real devs around me who would say that programming is easy. My colleague comes up to me and says "you know, mate, programming is easy", something like that? Politicians/media "experts"/programming advocates/managers can say anything, that "programming is easy", "No code/VR/AI/Zettelkasten is a thing", "developers, developers, developers". It's just words from outside. The same if I suddenly began to talk about how easily we can defeat the problem of global warming, for some reason (maybe because I have an outdoor thermometer). We just need to cool down the planet slightly, you know. Plus some events to draw attention to the problem (open up our refrigerators for an hour someday?)[0].
P.S. Ironically, the author also writes about piracy[1] (how bad it is, copying is stealing, her personal story about how he stopped, etc), but has removed the Hugo[2] copyright from footer (can be explained) and even meta info (?). I am not a lawyer, this is probably not a violation at all, but obviusly not a good tone.
> you hear about [impostor syndrome] when people actually hit those seemingly unproductive bottlenecks
I have not found this to be the case. My brushes with impostor syndrome come from working with peers who solve a problem or contain a body of knowledge that, on the surface, is professionally intimidating. As a senior engineer with a couple decades under his belt, I can state it is real.
programming to me is about solving our specific problem by creating are own abstractions on top of abstractions created by others... good programmer create simple but powerful abstraction. Programming being hard depends on the abstraction you are programming against.
The author does a poor job at connecting several themes in his article that remain quite unrelated to the reader:
1. Programming isn’t “easy” (whatever the definition of easy is)
2. An attempt to create categories for “easy” and “hard” programming: a toy website is the former, a large/complex piece of software is the latter
3. There are people who aren’t as technical as the others, undeserving of being called a programmer (the people with 2 years of experience who “play the diversity card” and oversell their experience, selling programming as a lifestyle, etc)
(1) and (2) pop up all the time in programming communities, and I believe it’s due to how geniune encouragement is expected to be like in certain cultures (“it’s easy! you can do it!” vs “it’s hard work, but it will pay off”). One of these sentiments wouldn’t serve its intended purpose in the anglosphere, the other wouldn’t work in Eastern Europe. There is a definite cultural aspect that we’re not considering in these discussions, and it applies to most communication online. However, it’s especially apparent when more abstract issues are discussed, such as whether or not programming is easy, what exactly is programming (also touched upon by the author when he ranted about HTML), and who exactly is a programmer.
This opens a whole other can of worms: programming gives people a lot of power (being in demand, mobility, financial independence, opportunities, relatively safe work) at a relatively low cost (being accessible to everyone with an Internet connection, or a computer comfortable enough for programming, provided they have the time to have a hobby). As per our current dominant cultural values in the programming community - where we believe ourselves to be intelligent and rational -, it would be a taboo to believe that someone is undeserving of this autonomy or even prestige, therefore when “programming is easy” meaning “it’s accessible, in general, to everyone with a will and some free time, providing massive rewards in return” is met with criticism using an underlying disdain for the influx of “a different type” of programmer (or someone who works with programmers), it’s apparent that sometimes other programmers want to keep this prestige, freedom, and autonomy only to themselves, or a select “elite”.
The programming elite does the “harder” work; there is more prestige since there’s a higher barrier to entry/recognition (years of study of theoretical CS, mathematics, low-level stuff, etc). It seems unaesthetic, therefore, to be associated with people who can become successful through utilizing more social and marketing skills. There is no strong reason to believe that most people who promote their blogs or are “promoting” themselves using the “diversity card” are less technical than the other programmers who sit quietly behind their desk. There might be some, but overall, I belive there’s a strong bias against them from the self-proclaimed old-school, hardcore programmers.
There is a disdain for the more social, more entrepreneurial, more marketing-and-sales aligned technical person who knows how to utilize current social media trends to their benefit. It might stem from the belief that the better technical person is the more quiet one, the one who spends years programming their OS alone instead of engaging or even collaborating with other people (that’s a bit of an extreme example, though).
Another reason why more and more people are hyping themselves up is because it’s necessary. Not everyone receives a high salary or has a great boss. There’s plenty of people who work for free or very little money, having skills that would be much more valuable if they worked for someone else. But not everyone has the same network (which is incredibly important - imagine being all alone in this) or word-of-mouth recommendations. They might be acting proactively to get a better offer somewhere else. Sending in your CV without any online presence doesn’t always work for everyone. I think we should be more empathic towards people we don’t understand, instead of feeling immediate disgust and throwing them outside of the community, so to speak.
Either way, any discussion around “is the field XYZ hard or easy?” doesn’t exist in a vacuum. We’re dancing around status. If something is harder, especially intellectually, we believe it deserves more respect and perhaps even higher status, higher ranking in the professional world. If something is highly compensated, we also assign higher status to it, naturally. There can be many different types of programming that can be in either the easy or hard categories at any time - and the low barriers to entry make it much harder to judge someone’s status, and our relative standing.
Doctors and lawyers are considered to be higher-status not only because what they’re doing is “hard”, but also mostly because of the gatekeeping, the qualifications and licenses needed to be called one.
This discussion keeps popping up because a lot of programmers want the confirmation that they’re high-status, but it’s not that easy.
> Guys, can we collectively try to make people understand coding is not difficult?
>
> It is literally googling and fixing bugs we caused in the first place
(From a quote in the article)
I see this dumbshit rhetoric more and more, but do people actually think this? It feels like someone on the peak of Mt. Stupid from the Dunning Kruger effect would say...
The same is more or less true for programming. A simple stack of JS, HTML, and CSS is pretty easy to get going. And if you're content to make marketing sites for advertising companies or similar, then go nuts. That's your simple jam and you rock out on it as much as you like.
Other people want to learn violin or weird keys or timings or cross rhythm. They want to woodshed some African drums and mix them into complex arrangements. And you know what? It is harder than playing a simple guitar for a simple song.
We have the same thing with software, and once you've put in the years you find a sort of series of specializations that make you stand out a bit more and get you a bit more money.
So when people say "programming is easy" what they really mean is that it's easier than most people expect it will be for the financial incentives it provides. Compared to, say, structural engineering which takes four years of focussed study then a long period of practical understudy, software is easy and it pays more. Almost any structural engineer can become a data analyst or junior data scientist and make around double the salary within a year or two.
Yes we've all had the frustrating semicolon days, but there are highlights too. Fast feedback, ease of learning new technologies, ease of scaling to millions of customers. There are many advantages and I think they make up for it.