Ask HN: Is programming culture immature?
Programming is intellectually challenging, and that seems make insiders and outsiders assume that in order to have some success as a programmer, one must be intelligent, rationale, sensible, or heaven forbid, wise.
Yet in my experience, it doesn't take a lot a long time engaging with the digital-technical community at large to realize there is often a large gap between intelligence and wisdom or even basic sensibilities. A field which has so many tools to objectively quantify their work and the result so often are debates displaying poorly concealed biases and egos.
I was visiting the Star Citizen subreddit where a user posted a readable, short, simple proof of concept to improve a longstanding inelegant UI element.
I read debates about languages and see the most reasonable of authors walking on egg shells and writing caveats like they are commas lest one misstep allows a snowballing tirade of people missing the point.
And more universally, I see people who have acquired anywhere from basic to advanced competency spit jargon of the most specific like it is poetry, in a field where learning specifics on the job is the norm (and not that difficult), it seems people cannot resist using obtuse language to virtue signal their intelligence relative to other people.
There are obviously exemplary members of the outward facing tech community; they often have great success for being the foil to what is above, but more and more I become frustrated and begin to believe that progress in digital technology is greatly hindered by the low quality background of interaction between those who use it.
I say this fully embracing that in a domain like tech where extremely complex and nuanced problems need to be solved that disagreements, sometimes passionate ones, will need to be resolved one way or another - I am not against or complaining about that fact; I am simply growing tired of what I think most reasonable people can identify as basic immaturity and the surprising and disappointing commonplace nature of it.
Do I have to issue any more caveats? I am dead certain their have been numerous and highly successful workplaces which were the anti-thesis to these complaints.
I have less experience in this space and in life than many of you - so please offer your perspectives.
131 comments
[ 3.1 ms ] story [ 189 ms ] threadMost people read something and go on without commenting, it's only when they have something to make it worth the bother of a post that you'll get a response. This is why you'll see disproportional lots of nit-picking in responses here and elsewhere on the internet.
I spend a lot of time and effort in most of my posts here on HN trying to anticipate criticisms and being defensive as a result.
As far as using jargon, it helps remove ambiguity to help ease getting a point across. It's not something that people do to deliberately exclude people, for the most part, though I'm sure there are twits who do otherwise.
"Woodworking Mindset" is one antidote: https://scottstevenson.substack.com/p/lego-mindset-vs-woodwo...
A lot of the time being too high in conscientiousness actually makes it super hard to be creative: https://scottstevenson.substack.com/p/how-to-finally-make-so...
Further, commentors on any particular subject are, I think, statistically more likely to be monomaniac obsessives, and that correlates with poor social skills (e.g. truth-seeking at the cost of empathy). In other words, autism.
The cpp community is possibly the worst offender on some of the points. Speakers walking on eggshells and having to have a laundry list of caveats comes to mind.
It's more mature in the sense that you probably wont see a lot of memes, the insecurity and ego still permeate the venue and community.
I'd hate to put myself out there doing a talk and be on the receiving end of that sort of indirect criticism. It wouldn't be feedback to the person, it'd just be something for us to argue about whether they're exhibiting a given behavior or not.
They applied all the rules and "best practices" they saw on Medium with maximum strictness (of course) and were very adamant on doing everything now in the "right true way" in the codebase.
I had trouble putting words on that behavior, describing it as "religious fundamentalism, but with code", so I'm glad to finally have a better word for that.
* It was a simple corporate website, with a few, simple forms (though with visuals bells and whistles added), and some semi-customized pages. It could have been a minor project (in term of technical complexity, not business impact), and somehow was so overcomplicated that there was like 5 or 6 front-end dev working full time on useless churn, like adding more configurability to their deployment process, or changing a library with another based on the number of Github stars.
From the above perspective, programming is more like politics/fashion than mathematics. There is in general insufficient respect for scholarship, a lack of universally accepted authorities, a consensus on what's high quality and low quality. There is too much dispute and room for profitless argument.
PS: We got attracted to this field; what does it tell about us? :P
For me personally, it's frustrating how so many new ideas are really solutions to problems tech itself has caused. I like to say that Docker is great, but really it shouldn't need to exist - packaging complexity is self-inflicted and a sign of an immature discipline.
Also, what other discipline can spend millions of dollars, and 10s of thousands to millions of man hours building a package/framework/language/ecosystem, then decide a few years later that "meh, seems dated", and "look, this new stuff is so refreshing!". Again, the inability to focus is a kind of immaturity.
We don’t hear about them that much, but almost anyone using k8s is not using docker at this point.
> An operating system is a collection of things that don’t fit into a language. There shouldn’t be one.
The programmer equivalent might be refactoring variable names to "int i_FallDistance_mm" or working in crypto.
If you aren't sure if your current job is one that an engineer would do, you could consult the engineer code of ethics. Broadly:
1. shall, in their areas of practice, hold paramount the health, safety and welfare of the public and have regard for the environment.
2. shall undertake only work that they are competent to perform by virtue of their training and experience.
3. shall conduct themselves with integrity, honesty, fairness, and objectivity in their professional activities.
4. shall comply with applicable statutes, regulations, and bylaws in their professional practices.
5. shall uphold and enhance the honour, dignity, and reputation of their professions and, thus, the ability of the professions to serve the public interest
https://www.apega.ca/docs/default-source/pdfs/standards-guid...
Because it can afford to be like that.
You seem to be treating volatility as something negative. But it's only a side effect of software engineering industries being incredibly cheap to launch and scale.
You can't start a transnational construction company in a garage. But you can start Google.
This is absolutely true.
One real example of this phenomenon in my opinion: the rise of JSON. In the 90's, the XML was invented to be the silver bullet of the myriad of ad-hoc formats for structuring documents that existed in the wild. So in the XML stack you could find the XSL to ensure the validity of an XML document, the XPath to be a querying language, the XSLT to be a language for writing transformations, etc.
I guess that in the 90's many people regarded XML as the dawn of an era of strict correcteness between data exchanges and the elevation of the contract-based design.
At some point though people deemed XML too verbose and started using JSON. Now with JSON there are multiples conflicting implementations of basic things like a schema mechanism and files and API's that rely many times on natural language to be defined, so an obvious retrocess only because of "verbosity".
You can see this random walk in many other places, with frameworks reinventing the same thing over and over and getting traction besides implementing something worse.
I guess that since technology is a field that receives a big influx of people, the dynamic of the field changes to support people who don't understand completely what they are doing, this doesn't happen with mathematics/chemistry/physics because it's you who have to adapt to them.
Tangential, but this is seriously uninformed. XML is a subset of SGML, specified by SGML's original creators, implementers, and users (the SGML Extended Review Board at W3C) as a simplified meta markup language for the web. What has been projected into XML beyond this original purpose is truly astonishing, though, and while that's true of the web as a whole, XML has failed this primary purpose, too.
That's exactly the sort of discussion that encourages what's called "bikeshedding". If someone says "we should fix x because it will be much faster", that tends not to generate rants. If someone says "we should fix x because it would be easier to use", it generates complaints. Mandatory XKCD.[1]
> There is constant "change".
This is especially true in the user interface area. Fussing with user interface elements is a popular way to indicate that the product has a new version. Look up the history of Microsoft Windows screens. There are lots of historical pictures, so you can do this easily.
It's a management problem, too. The head of the Stanford business school once said that the main job of management is "change". Not "improvement". There have been at least 22 versions of Tide, the laundry detergent. A line from a marketing text: "The most effective phrases are FREE and NEW. You can't always use FREE, but you can always use NEW."
[1] https://xkcd.com/1172/
On the contrary, I think the problem is that these tools do not exist.
For instance there is the continuous thread about the difficulties hiring and being hired.
There are various snake oil practices such as stack ranking and OKRs (e.g. if you want to drop 20 atom bombs on your startup... OKRs. They are fine for monopolist pyramids that will succeed no matter how much they fail who want to create safe spaces for narcissists while heading off any threats that sensitive and intelligent people might pose to the power structures)
It is very possible for one programmer A to say "programmer B is an idiot" even when programmer B can say "I picked up a project that A was working on and going in circles on for two years and finished it in one year."
I think there are several reasons for this: low barrier to entry, short cycle times, almost zero distribution cost. Compare delivering new or updated SW to designing and machining a part or making a PCB.
That's what makes computer engineering so exciting and also sometimes frustrating.
It's not necessarily a sign of immaturity, as a consequence of the audience and medium. Text is extra hard to transmit nuance with, and if you just get straight to the point any stakeholders with a side-interest will go go rabid.
* Some people think "Microsoft rules, and Linux sux" and other people think the opposite
* People talk about project management the way that they talk about agile (I'd say that agile proponents and detractors are equally bad... It's the style of the discourse that is the problem.)
* There is a general lack of respect for all of the skills that it takes to make software: for instance all of the trash frameworks (e.g. Microsoft's failed MVC for .NET) written by systems programmers who think they are better than applications programmers but have no idea of how to structure an application systematically.
API layer is just a thin layer that either calls some other code (layered architecture) or is delegated to the "outskirts" of application (ports and adapters architecture). There should be no references to framework code in the application "domain" (DDD) code. By using alternative (beatter) IoC container you can get rid of any dependency on microsoft libraries.
Now I write in Java/Spring but the attitude that I use is the same. No framework code mixed with domain code. Sometimes it means I need to write stupid adapters that e.g. use spring @Scheduled but it allows me to switch to another framework without much work. For some people this will be over engineering, for others this would be good architecture.
Also, some might say the jab at ASP.NET MVC is an example of what OP is talking about.
Computing science is also quite immature, because of all the mathematical sciences it is by far the youngest. I don’t think that’s what you meant though.
That said, I think programmers are prone to some of this simply due to the fact that programming requires a baseline obsessive attention to detail that most people don’t want to think about. Combine this with the fact that businesses need tech and the situation has led to a lot of secure jobs for technical people with poor social skills. This has led to a situation where a lot of people can get by in a sort of comic-book-guy bubble of expertise without having to learn anything about civil discourse.
Now I think it bears repeating, these people are a tiny minority, definitely less than 5% in my experience working with hundreds of engineers over the decades. It’s just the increased size of the community and incentives online that cause them to bubble up without consequence.
Since this would be done by a programmer, programming communities would be among the first ones targeted.
Some upfront thinking would help us (developers) save a lot of effort and frustration
And, obviously, software is in charge of actual security in the real world, and the track record there is not exactly flattering! Safety as well, of course, but luckily safety-critical software is a much smaller and usually more rigorous subfield, quite unlike the case with security.
Last time i had to get roadside assistance, they couldn't use a mile marker / highway location reference. They had to have something to type into google maps in order to dispatch help.
Could they have gotten to me if google maps was down? Probably but i'm not sure. Either way, it wouldn't have been the practiced default and that matters.
1. Computer programs are far more complex (and complex in a hard to analyze way) than mechanical systems
2. Programming is (still) a relatively immature field, and, and a result, it doesn't have the institutional knowledge and best practices that make certain failure modes highly unlikely
I think (2) is an underappreciated point. If you look at the history of e.g. boilers and steam engines, the early years are absolutely rife with examples of boilers and steam engines exploding in spectacular ways, often killing people in the process. It took years for standards of design and engineering to develop which made those failures exceedingly unlikely. Another example comes from aeronautical engineering. The Comet jetliner, for example, suffered from cracks that developed due to metal fatigue that was exacerbated by the design of the windows. These cracks led to crashes that killed hundreds, and, in response, standards were created and modified to ensure that window frames were properly designed and reinforced to prevent cracks from propagating. Furthermore, Dan Luu has done some work [1] in analyzing how cars fare in accident types that haven't been incorporated into safety standards, and he finds that their performance is often quite bad.
Most "traditional" engineering is like that. It's not that the engineers are personally paying more attention to failure modes. It's that they're following standards, and as long as the standards are followed, the failures that necessitated the creation of those standards are prevented. Programming, unfortunately, is still new enough that many of the standards we need haven't yet been developed, and most practicioners are new enough to the field that what standards do exist haven't really propagated across the field.
[1]: https://danluu.com/car-safety/
[1]: https://www.hillelwayne.com/post/are-we-really-engineers/
[2]: https://www.hillelwayne.com/post/we-are-not-special/
[3]: https://www.hillelwayne.com/post/what-we-can-learn/
It requires some careful attention, planning, and some honed skill, but so does building a bridge that spans a river, so does cooking meals for a party of six on time, so does sewing a shirt, so does composing a piece of music, so does drawing a cartoon or a comic strip.
Programming isn't the first occupation that requires problem solving skills. A tech boom and high salaries have definitely convinced a lot of programmers who haven't had much other world experience that it is. The way we talk about and treat programmers as an elite class has only helped to grow that image even more.
As you said, a lot of highly paid programmers who never cared to learn social skills, or worse, actively despise working with others. However, I don't think this is an accident or a fluke, it's behavior that's been encouraged and reinforced from the bubble. As the tech boom wears off, we might see this change.
What could cause this though?
The Fed having a tight-money policy to control inflation leading to widespread layoffs in existing tech firms and less investment in new ones, and what would make it more durable is some breakthrough outside of computing leading investment in a different direction in the next easy-money period.
The field, the industry, the profession… whatever you call it… it’s not even a century old. Cooking, metal work, civil engineering, architecture, etc. etc. go back millennia and transcend civilisations. Humanity has had a hell of a lot of time to get good at those things, each culture throughout history discovering and refining its own methods until now, where we see them fused together in a globally connected world.
Software is not even a century old. We are still in the birth of a new industry, everything is rapidly growing and evolving, and we don’t have any historical context to rely upon except perhaps mathematics.
We might have hit our limit on CPU architecture and how we write software, as far as we know we’re the first to reach this point. But the next generations, the next civilisations, can take our primitive work and discover something we couldn’t.
It’s only going to become more important as time goes on. We all just got in early, in the middle of the chaos. We’re gonna go through this kind of maturity problem quite a lot.
Yes, I think programming culture is immature as in there is lots that isn't yet well understood. I think the entire industry of software development is the same. But I think this is more a result of how young the field is compared to others. We've been building bridges, roads, etc for hundreds of year, but we're still trying to wrap our heads around software.
I think this is what makes it great. Yes, there are egos, and folks who strongly hold points of view that I'm sure history will prove incorrect, but I think that's what makes this fun.
To give an analogy - I've noticed that when my friends and I all get into a game (dota, back in ~2008, for instance) at roughly the same time, there's this magical period full of fun and discovery where we're all trying new things and exploring how the rules of the new space translate to outcomes. Sometimes we get suck in a local max and then someone dramatically finds a new mechanic that changes everything. This period is the golden period. This tapers off as we start to know which strategies work and we just continuously use those to win.
This is the point where the goals shift from discovery to execution. I've found that playing games past this point is just frustrating for me.
So, yes, I think we're still in the wild west era of software development, but I think it's kind of fun! I don't think it'll last forever and it will probably be better overall when it ends, but I'm here for the ride.
I agree with the overall point though, we’ve been making roads, constructing buildings, doing banking for centuries or millennia, compared to a century or less of software. But those fields aren’t 100% mature either — finance cooks up new derivatives, and we find new materials, techniques for constructing things. In some sense I think foundational principles for tech are already there, but not as mature as other industries due to time.
We've all developed our own biases based on experience and along the way we form a mental model of how "software" should be built. For example, many of us have been burned by some technology or language and we warn people away from it. This isn't a bad thing. It reflects, to an extent, contextual knowledge that isn't really going to be found in a google search or by reading the tutorial. Take it with a grain of salt. That negativity probably harbors some contextual issues that engineer ran into at some point. Noted.
As engineers we take pride in our work. No engineer likes to have his work challenged, so we all become defensive about our way of doing it. Over time, if your not careful, we can get pretty prickly about how to do something. Rather than immaturity I'd call it being resistant to new ideas. Its the old adage about "if you have a hammer...".
There's a flip side to providing caveats and walking on egg shells: The culture is terrible at providing feedback. It's given when not requested, it's usually very very pedantic, or possibly delivered with some degree of irritation.
One thing that I find helps: separate things into objective and subjective categories.
code quality, best language, good design, cleanliness -- examples of subjective measures. They're going to vary by person, background and experience, thought processes, etc. They make for entertaining discussion topics, but not usually productive ones.
These generally are also the areas where people's egos and self worth get wrapped up. No one wants to feel like they're producing unclean code.
I try to focus more on objective things: does it produce the correct result? how much time will it take to on board someone to x y or z? It usually helps keep the discussion productive and helps keep egos at bay.
It's difficult though. People have opinions, and they want you to know about them. and they want those opinions to be facts. And it's most likely something we're all guilty of.
This applies to conversations about performance a lot, too - so many debates on performance happen without any benchmarking or attempts to measure.
> If instead the culture had focused on the more subjective aspects of language choice, I think we would be a lot better off.
Maybe? Who's to say what would have happened in some alternate timeline. There's no way to get an actual answer, so there's not much value beyond entertainment in discussion. Perhaps the exercise might provoke thought.
I could write a CLI or GUI Java program, that would run on any OS, for which there is a JVM, and that was easier than doing it in C, C++, Delphi or Perl, which were popular at the time.
As far as I know, at the time only TCL/TK offered something remotely comparable in portability for GUI apps.
Its also a sign of immaturity to have your value determined through eternal views and society, aka to be eternally stuck in high school, without experiencing the growth events that allow one to transcend that scenario via creativity.
I don't want to use Windows, when I hunt for jobs I avoid jobs that do not offer mac/linux laptop. This is probably immature (or as programmers we are simply spoiled).
There is hype. Some people that for 10+ years where writing Java are jumping ships to learn Go. Go is like Java 1.6, the error handling is cumbersome. Yet all those people say the simpler language is the better. They are the same people that a few years ago were cheering for functional programming in Java and streams...
Finally we have this cult of x10 programmer, being oncall 24/7, macho work ethic (workaholism) and changing the world. Seems like kids gone wild.
I don't think that is immature at all. As a professional it is perfectly reasonable to expect to have good tools. If, for what your job involves, Linux / Mac is significantly better (for you) you are right to insist on it.
If you were applying for jobs as a carpenter you'd be right to ignore any that only provided a hammer.
I see no reason to assume all brains will work equally well with every workflow. The important thing is what gets checked into the repository, not the sequence of keys you pressed to get there.
(I am currently that person, with vscode and emacs. I have better things to do than retrain myself out of a set of keybindings I've become very efficient with.)
Some folk view and use cars as A to B transportation, and some care about how wheel camber angles affect driving dynamics. Ultimately, it boils down to taste, knowledge, nuance.
I dont think the windows in itself is the issue here. To my experience, when the employer enforces the use of windows, its because you really cannot use something else to do your work because of some specific network policies which disallow you to connect to the network itself. Also the use of windows goes usually hand in hand with other stupid policies, which forbid you to do anything on your computer which is not part of the job. Sometimes it goes as far as not allowing you to change your wallpaper or restarting your computer in the middle of your work without even warning you every day. I don't blame people for choosing to work in other companies where they don't have to fight the security department when they need to install the basic tools for their job. The tooling you use should be decided on the team level, not the whole company level.
And yeah, the industry very immature: it is idealistic, hype-driven and full of cargo cults. Which makes perfect sense: when you convinced yourself that you are a great intellectual, but all you do is building REST APIs, this makes you uncomfortable. So the next natural thing to do is join a cult. Maybe even start preaching. This gives you a sense of superiority you've been looking for.
When you get past that point, yea, then I agree. The intellectual challenge for most programs is gone. Not for everyone though, I have a friend working for a HFT firm. The shit he encounters is hardcore.
Imagine a world where all programming was done via heuristically-derived ChatGPT prompts spelling out what the system has to do in lawyer-like detail. That's what lots of non-coders have in mind when they think of what "coding" must be like. Of course that would be totally unworkable; coding only works because it's formal and 100% reliable.
This is not true for distributed systems: clock skew that is unpredictably different on different devices and networks are inherently unreliable. Real word physics is messy. :)
I think there's danger in this mindset. Unlike math, programming is always directly tied to real-world problems. And those are defined by humans. Who, as we know, are not very good at being formal.
In my experience, the biggest obstacle is actually not recognizing the informal part. Trying to stay in our own little world of formalities and treating the real world as a nuisance to our grand designs.
Calling yourself a computer scientist might be pleasing to our egos, but at the end of the day most of us are software engineers. We are the conduit between formal and informal. There's no shame in that.
Huh? You think that math is not tied to real-world problems? That it's not useful for modeling the real world? It's not like programming is doing something inherently different.
Some of us saw a CS degree as a route to living in your own world of imagination and are disillusioned by finding out just how much that is wrong, or defensively cling to that illusion to the point of near fisticuffs if someone tries to burst that bubble.
This feels especially true in the front-end. Whenever I try to learn new things I always try to find the online communities, the main books, the podcasts, etc. I try to find the people down to bikeshed about something most wouldn't care about.
I feel like this learning strategy has been especially effective in the front-end world. If you start a new job, chances are you're gonna have a huge chunk of your stack be totally new just because of how many solutions there are for everything out there. I feel like the main value-add I bring a lot of times is just knowing what's out there and what the best tool for the job is. Most of the time I haven't actually used that tool
The hard part is cutting through the bs and knowing what's hyped because of a certain interest group and what's hyped because it's an actual improvement. For that, I find you usually do need to have some hands on experience
In academia, sure. Esp in research.
It takes most people thousands of hours of practice to get good at it, and a lifetime to master it. I think most people of average intelligence can get to high levels of competence, but it's definitely not easy.
This is also what I think makes for great system architects and really differentiates them from “just” a programmer. The ability to reason about all the trade offs at each point and make that deal with designers+users etc in an amicable way. A good architect understands compromise and nuance whereas many software engineers often see it as a puzzle with one true solution.
So debate often becomes: there is one true way to do this. A difference in opinion is a difference in truth.
When I supervised teams, my favourite moments with junior hires was when they’d hit a problem that they couldn’t reason about without compromising something, and also when they’d invariably break something in the process because “it should work this way”.
It’s the best teaching moment. They can learn that best is relative. What may seem ideal is coloured by so many facets they don’t consider in the limited world view they’ve collected of the systems thus far.
The best are when they put out a UI based internal tool (so no designers involved). They’ll often get responses from users that they can’t figure it out but their own engineering mindset often can’t see past their logical flow and familiarity, to see to the lack of intuitiveness within a greater world view. Again, a really great teaching point about how intuitiveness is often non tangible.
Anyway all this is to say: as programmers we often think in absolutes , in binary so to speak. IMHO that’s one of the biggest issues in our community culture. It’s why we often fail to put ourselves in others shoes or fail to have discourse.
I have read some of the "foundational" works, at least well enough to know roughly what's in them. But I've only had the privilege of applying TAOCP a couple of times in my career. Similarly for other techniques from calculus to dynamic programming algorithms.
99% of the time, I try to focus on the simple solution, one that fits the business needs closely. A few times a year, I encounter a situation where a small amount of cleverness (or deeper theory) has a big payoff for the business. Then I indulge myself carefully. And in those cases where cleverness is actually a win, simplicity becomes even more important.
If I had to make an analogy, programming is a bit like being a fine woodworker with a limited budget. You want to solve the problem, with quality work, at a reasonable price. Finding the right balance can be extremely satisfying, and it can help an organization achieve ambitious goals.
But then you talk about using obtuse terminology as a virtue signal of intelligence or something. Have you read historical, literary, or other analysis / commentary texts? Such terminology abounds in those communities, are they immature?
The Internet is just a weird place, which is just a reflection of how people are.
Some reasons:
- The field skews young. Like it or not, younger people are more obnoxious and doctrinaire than people with more experience.
- It used to be that the field attracted people who loved technology for its own sake and loved creating things (there was not much social cachet or recognition). But now it increasingly attracts people who are much more competitive and feel the need to project confidence to the point of being arrogant (any field that throws off large amounts of money eventually attracts these types). They are drawn to the money, recognition or a religious zeal to 'change the world'.
- Technical decisions such as libraries/languages/frameworks to pick are often the only avenues for self-expression and autonomy that are left in modern companies. Product Managers are often non-technical (still!) and tend to infantilize programmers. Programmers, despite making more money than other functions and providing obvious value and leverage, still have much lower standing in companies.
- Religion has disappeared from most people's lives, and for many, the religious fervor is replaced by fervor of a different kind. This is also why SJWs have proliferated everywhere. People need to believe and act on their beliefs.