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.
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.