12 ms·

I started attending college a year ago. At that time, I didn't know much about programming: just a bit of C and some Python - enough to make first year college

I started attending college a year ago. At that time, I didn't know much about programming: just a bit of C and some Python - enough to make first year college projects. After I started frequenting HN, I came across a lot of comments by developers on programming languages, toolchains, libraries, etc. Even though I didn't understand their arguments, I still believed what they said, because I thought they were experienced, so they must be right. Even though I hadn't used the tools personally, I started developing premature opinions on them: Java is verbose, so it must be avoided, PHP is inelegant etc. These opinions also gave a feeling of security: because I thought that I had chosen the right language for programming (Rust!), the right operating system, the right text editor (vim), and the right window manager (i3). This made me arrogant, because I saw myself as above my classmates, who were still using 'inferior' tools and still struggling to grasp the concept of command line arguments. Over time, I realised that I was just basing my beliefs on HN comments, and it is not healthy in the long run. This article helped me a lot towards realising that. Thank you for posting this article :) Edit: grammar

SilverRed 5y ago
To be fair though, there are better and worse tools. There are legitimate reasons to say that PHP should be avoided and that Rust is a good choice. It's just important to understand how much weight these opinions have and understand why they apply. If you are building a bulk file rename tool, it doesn't matter how you do it as long as it works. If you are handling untrusted data from remote sources, then you may want to consider if C is a good idea.
- Flex247A 5y ago
  I agree with your points completely. Some tools are just better designed. I was talking about the premature opinions I had on these tools before I had even used them, or seen them in action. This is a problem as it limits my teamworking capabilities. For example, I decided to do the first year programming project all by myself as I thought nobody else could do it. Edit: added an example
- moksly 5y ago
  I have a somewhat funny anecdote on this. One of our sister cities had a tool for handling city-water or something along those lines, that was build in ASP Web-forms. All the city engineers were perfectly happy with it, but the developers behind it were worried that ASP web forms were becoming obsolete. Not really an illegitimate concern I supposed, but what they did was hire a company to rebuild it in AngularJS. So now they have a technology nobody else uses around here, while web forms simply turtles on because of how much legacy it has in various places that aren’t upgrading it.
dmos62 5y ago
To have access to (or sense to use) better tools for given task is good. To be smug about it is bad. Actually, drop everything about technology in this discussion: being prideful is just bad.
moksly 5y ago
Good for you! I think one of the more important lessons is to realise that the programming community can be very disconnected from reality. This is especially true for HN with its heavy focus on “interesting”. Judging by HN, things like Erlang, Rust and previously Go, would see a lot of attention and so would the Kubernetes way of doing CI/CD. Interestingly there hasn’t been a single Rust, Erlang or Go job offering available in the region of the world where I live since I started tracking them out of interest after a similar discussion on HN in 2019. There are however a constant demand for JAVA, C# and PHP developers. Because that’s the languages that are used in my region of the world, and as interesting as something like Rust might be, you’d have a hard time actually finding a job working with it. Even JavaScript isn’t that outspread here, if what you’re after is a full-time JavaScript job, because there is almost always a JAVA, C# or PHP backend to go along with it. You can of course find C++ job, there aren’t many, but there are some and I’m sure some of those places actually use Rust behind the scenes, but they don’t advertise it. Anyway, I think my point is that there can be a big disconnect between HN and what you’re actually going to end up working with, and you’re likely not going to work with just one toolset for your entire career either. Before I became a manager, I spent almost a decade working mainly with .Net, but with the rise of things like Azure Services I stated working more and more with Python and Powershell, these days I almost exclusively work with Python as I’m mostly handling data for BI or management purposes and let the programming get done by my developers. We have recently picked up PHP though, which you likely wouldn’t think would happen in 2021 if you go by how dead PHP is supposed to be. Well, it so happened that there is a big open source project in my country that utilises Drupal to create a “forms generating” CMS system, that we want to be capable of building modules for, which means we needed someone to learn PHP. Another really valuable lesson in humility I learned, and it took me years to do so, is related to the arrogance many software developers adopt when we get into the real world and start building things with the business side. Because our skill-set is so linked to dissecting and understanding problems, some of us adopt the unfortunate habit of thing we know... well everything. I’ve been arrogant enough to think I understood how our payment business process worked better than our director of payments, and of course I didn’t, but it was just so used to handling problems that I though I did. If you can, do better than me and apply your humility to everything, not just tool chains.
- 5y ago
lstamour 5y ago
I wouldn't say the primary takeaway from this post is to remind programmers to be humble. It's a takeaway, yes. But humility comes and goes, and reminders often take the form of bugs in your code that you didn't expect. I would argue the post is primarily about complexity, and in school you probably haven't seen how complex software can get because most projects have to be started and finished within two to three months. Once you start working, you'll quickly discover that the complexity of existing systems can be overwhelming, but this is normal. After 3-6 months working on a complex codebase, ideally with a team to help you, you'll have some idea of how the complex system works, and even if that idea is wrong (in many, many places), it will help guide future changes to the system. The point then, of reminding programmers to have humility, is less about hearsay on the internet and more about the need for tools and languages to make life easier for the individual programmer trying to read the code, then plan, make and deploy changes to a live system. If you're lucky, you'll feel like the system makes sense but changes too quickly. If you're unlucky, the system will make little sense and it'll be entirely your job to fix it or put up with it. Usually, hopefully, there's a middle-ground, where the system works well enough you don't have to make changes, but you're probably not entirely satisfied with it either. Humility can also be the reminder that just because a system looks broken (to you) doesn't mean it needs fixing right this second. If you can spare the time, it's almost always better to try and understand an existing system's quirks before you set out to redesign it and end up re-implementing some of the same quirks yourself. I'll echo mentions elsewhere in this thread and suggest John Ousterhout's A Philosophy of Software Design as a good book on the subject of complexity and API design, but to newcomers to the field, I'll leave the warning that it doesn't cover TDD as much as it could and it also doesn't cover modern Scrum/Agile practices and how development fits in with product design and company goals. But I still highly recommend it.
- lstamour 5y ago
  I also recommend listening to podcasts like Changelog[1] in which developers are talking through how they approach problems etc., and trying to back up what you don't understand online by watching YouTube conference talks, ideally ones with examples in them from the real world. Usenix talks, for example, tend to cover a lot of real-world engineering-at-scale challenges. The more you hear how programmers often make mistakes, the more the lessons around humility will sink in. :) [1]: Re. changelog, and the subject of both mistakes and TDD, https://changelog.com/gotime/174 https://changelog.com/gotime/174 was a great listen also. Testing has gone from niche to mainstream back to "the best projects do it, but maybe only when forced," and it's interesting to listen to modern takes on what to test and when.
goto11 5y ago
Lots of programming wars is just tribalism. Java is disliked on HN because it represent "enterprise" - big long-lived organizations which maintain a codebase for decades and therefore conservative. A different tribe than the startup tribe HN represent. Java is not in particular more verbose than say C or Rust for solving the same task, it is just a random slight on the language of a different tribe. HN is a great community, but it has a very narrow perspective on the world. As a beginner it is fine to chose to master one language first, but in the long run you should not "choose a language", but rater learn to learn any language, and understand they all have their strength and weaknesses. But there are so many choices of tools and technology in this industry and it is impossible to learn it all. Tribalism makes the world simpler because it narrows your perspective.
- deleted 5y ago
  [deleted]
- internetslave 5y ago
  Java is miserable to write. You don’t realize this until you work with other languages. It was literally built with guardrails to keep enterprise coders from getting too creative
  - podunkPDX 5y ago
    I can’t speak to the actual act of Java development, but I can speak to Java applications from a sysadmin perspective (15 yr Sr. QA Engineer to a 3 yr Linux admin (don’t ask)) — I’ve got no real beef with Java from the development side, but maintaining some of those stacks in production is pure pain.
    - lmm 5y ago
      Huh? Java is probably the least demanding stack from the sysadmin side - no big chains of library dependencies, no docker, strong backwards compatibility that means you can fearlessly upgrade the language. All you have to do is keep an up-to-date JVM installed on your servers and deploy single-file fat JARs to them.
TeMPOraL 5y ago
The flip side of having "premature opinions" is that, at the very least, you gained a lot of data points early on :). It's kind of like with assembling a tricky 1000-piece jigsaw puzzle. You assemble the frame first (like everyone always does), and wonder how to fill it in. You could pick the most obvious feature on the reference picture, start there and focus on expanding it piece by piece until the picture is done. But what I imagine most people do is first speculatively placing all the pieces that seem trivial to match to corresponding picture features, in order to reduce the number of unplaced pieces quickly, and give themselves lots of starting points to expand their solution in parallel. This approach is useful despite it commonly turning out later that some of such early starting points are placed completely wrong - puzzle blobs get easier to position correctly once they grow in size. It's a long way of saying, if you keep track of confidence levels of your beliefs, instead of taking everything you read on the Internet as certain, even off-hand remarks on HN can be useful in navigating the enormous space of technologies and philosophies that form the software industry.
daptaq 5y ago
> the right operating system, the right text editor (vim), and the right window manager (i3). As a TA I see a lot of people who also made these same decisions, maybe just add Arch Linux and zsh to complete the cliche. So you don't have tl worry, as this is actually relativly commom. But I don't think it is wrong to have intuitions based on stories, as long as these don't prevent you from trying out said tools or languaged yourself. They can be right, but they might also be outdated. Just stay curious.
- Flex247A 5y ago
  Curiosity is what caused me to frequent HN :)
- Agentlien 5y ago
  I find this interesting because I've always been suspicious of anything hailed as the next big thing and obvious right choice. I've deliberately tried a lot of alternatives. And yet, after many years, as I've finally stabilized on a set of tools and workflows I feel really works for me, it happens to include Vim and Zsh. Of all the programming languages I've used the one I've enjoyed the most is indeed Rust. I have even come to really enjoy Unity after ending up at a company which uses it.
  - daptaq 5y ago
    One thing is if you tried out different things and decide to use whatever tools you like, the other thing is seeing people use, eg. vim and just copying it without understanding why. The reason this perplexes me is that so many people end up with a working but ineffective workflow, for no real reason.
    - Agentlien 5y ago
      I know precisely what you mean. I've seen a few posts from people about how they finally transitioned away from Vim (or C++, or ...) after many months and then detail a long list of its flaws, all of which showcasing that they did not try to actually learn Vim, but rather try to work around it being Vim. It's a bit different from other tools and if it's not your cup of tea that's perfectly understandable. But why would you torture yourself like that if you're not willing to give it a fair chance? Edit: there are of course also those who do give it a shot, do learn the Vim way™, and then conclude it's not for them. That's great, I have no problem with that.
ChrisMarshallNY 5y ago
Rust is a good choice. It will serve you well. In my experience, I can learn a new language (and general style) serviceably well, in just a few weeks, but it can take years to learn the language in-depth, with the language being a “moving target,” as it evolves. I decided to specialize in Swift, and still have a lot to learn (I’ve been programming in Swift since the day it was announced, in 2014). Part of the reason for the time it’s taking, is because I have been using it to ship products, which slows exploration and research. What really takes time, is platform SDKs and frameworks. They can be real rabbitholes, with all kinds of idiosyncrasies and caveats. They, too, are generally “moving targets.” Good luck in your endeavors. I really enjoy programming.
chriswarbo 5y ago
> Even though I didn't understand their arguments, I still believed what they said, because I thought they were experienced, so they must be right. Even though I hadn't used the tools personally, I started developing premature opinions on them > This made me arrogant, because I saw myself as above my classmates As others have said, "good" and "bad" depend on the use-case; everything has pros and cons; but some things are still objectively better than others (e.g. if tool A supports more data formats than tool B, whilst being just as fast, just as secure, just as supported, etc. then A is a "Pareto improvement" over B; there is no reason to choose B for a new project). Whilst it's common to explain why something is "bad" (e.g. PHP encourages 'stringly typed programming', which makes SQL injection and cross-site-scripting vulnerabilities more likely); it's also important to explain why such "bad" tools are nevertheless widely used. For example, PHP is widely supported by free/cheap web hosts, is easy to set up (just copy a .php file to the server) and run (the URL is the .php file's path); it runs concurrently without needing shared state/threading/etc.; it has a built-in Web framework ('$_GET', '$_POST', 'echo', etc.); it can be embedded inside HTML files; and so on. This all helped it grow a large community in the Web 2.0 days, and lead to useful applications like Wordpress and MediaWiki, whose 'plugins' got many people into programming. This community of pragmatic (but often inexperienced) developers and their ability to quickly churn out Web apps has sustained itself to today; whilst the developers have matured, applications/libraries/frameworks have grown much more complex, the demands on the language are more diverse, and the language maintainers add new features and fix some of the language's underlying problems. I still consider PHP to be a particularly bad language, and would need an incredibly compelling reason to choose it for new project. Yet I know there are many reasons why people have chosen it, and continue to do so. Those aren't necessarily "pros" for the language, e.g. it often comes down to historical inertia and 'what we know', which is much less important for those just starting out, or working in a different field (e.g. data scientists), or facing a different context (e.g. Web apps implemented client-side, fetching data from managed cloud services). If we see the arguments against, but don't know much of the context or reasons things still get used, it's easy to make the assumption that others made bad choices due to ignorance. I think this is similar to Chesterton's Fence https://en.wiktionary.org/wiki/Chesterton%27s_fence https://en.wiktionary.org/wiki/Chesterton%27s_fence i.e. we should understand the reasons why someone did things in a particular way before we scoff at their poor life choices (after all, sometimes those reasons make it even more hilarious!).
golergka 5y ago
> Java is verbose, so it must be avoided, PHP is inelegant etc I think that these opinions are mostly correct, but you and anyone else would learn a lot if you chose to actually try Java and PHP and experience this verbosity and inelegancy first-hand, as opposed to just hearing about it.
deleted 5y ago
[deleted]
ChrisMarshallNY 5y ago
Personally, I dislike Java, and I never got good enough at it to develop any worthwhile opinions. That said, I really despise PHP, but spent 20 years, writing it, and doing a fairly good job, because it was the best tool to give me the results I needed. I feel that if we will use a tool, we need to take the time to become proficient with it. Here's an article that I reference fairly often. It's sort of a "reality check": https://veekaybee.github.io/2019/05/10/java8/ https://veekaybee.github.io/2019/05/10/java8/
- denton-scratch 5y ago
  "we need to take the time to become proficient with it." I have thought this for a long time. I have reckoned that it takes me at least six months full-time to come to grips with a new programming language (I'm 65 now, I learn slower, I'm retired, and I'll be damned if I'll learn any more). Over the years, I've worked in teams dominated by young whippersnappers who are very keen to learn the latest language/library/framework. But they don't allocate 6 months; they seem to think they can press their new tool into production after just 6 days' practice. The result was unsually unmaintainable code. I understand the motivation of the whippersnappers; they expect to change jobs within the next 6-12 months, and they want to be able to put the latest hot shit on their CV. But we ended up with systems that only a couple of people in the team could read, let alone maintain. Write Simple Code. Don't Be Clever.
commandlinefan 5y ago
> PHP is inelegant etc. ... who were still using 'inferior' tools Well... PHP is inelegant, and there's a reason that it's been abandoned. However, it's actually worthwhile to spend some time discovering that for yourself - if not about PHP per se, then about a different "blunt" tool. Part of the modern computer science discipline is working through exactly why so many simple-seeming solutions fall apart - it isn't obvious, and it's really important to internalize.
- denton-scratch 5y ago
  "Well... PHP is inelegant, and there's a reason that it's been abandoned." Abandoned? 79% of websites are still running on PHP. Let's postpone the funeral.
michaelgrafl 5y ago
Good for you. It's takes most people a lot longer to come to that realization.
bostonsre 5y ago
The more you learn, the more you grasp the massive quantity of knowledge that you don't have. You can't learn or improve if you think you know everything. I would say humility is the most important quality for an engineer to have if they want to be able to grow as an engineer. I've come across a small number of engineers that have lacked humility and acted as if they knew everything and they were a nightmare to work with. The first instinct they have when they approach most problems that they come across is that the issue can't possibly be caused by their code and you have to provide an unreasonable amount of evidence or a smoking gun to convince them to investigate their code. They design solutions as if they know the perfect way and they seem to lack empathy for users or others that may have to maintain that code.
smithza 5y ago
I am hopeful that you have misread the consensus that vim is most commonly used by those on HN... emacs is obviously the better choice and needs to be perceived as the best/most popular to keep the community active :)
axguscbklp 5y ago
Hacker News shows me the "Gell-Mann Amnesia effect" quite vividly. When people here discuss topics that I know a lot about, I often quickly realize that more than half of the people commenting are saying nonsense. When people here discuss topics that I know little about, I am often impressed by the jargon and tone of utter conviction.
kodah 5y ago
You sound a lot like me in the early parts of my career. Strong opinions are worth something when you're just getting started out, I can't quantify what they're worth but they do something beneficial in terms of speed. The downside is that anyone with perspective on their side is probably laughing (maybe giggling) at your strong opinions. If your journey is anything like mine you will end up driving yourself lower and lower into the stack until you wear yourself out. Ideological buoyancy will take over and you'll float somewhere higher, but you'll be much more knowledgeable and valuable as a result. All that to say, don't be too hard on yourself.
ozim 5y ago
I think that important part is "opinions also gave a feeling of security". I see it all the time in my daily life, people are insecure and mostly want some confirmation that choices they made are good ones. They buy a car and then they start saying that other car brands are bad or breaking so easily. They cannot face the truth if their car turns out to be a crap. Seems totally like programming language bros, and some people cannot stand that in other language they could make more money. So what? There are probably people using that language that make less then them. I don't want to live such life, I want to make mistakes and pay for them if needed. Lots of choices are reversible or can be changed, be flexible.
nickd2001 5y ago
100% agree that humility is important. And realising that at young age is great :) However, with over 25 yrs dev experience, I do believe its true that Java is verbose (and some of its frameworks hideously so), and PHP is inelegant. Both languages have improved a lot over the years, thanks to a bunch of smart people working on them. Having now decided your opinions were premature, you may one day come to the same conclusion based on experience. Python, OTOH, well, that's a lot of fun. Has its issues, but, overall nice to develop with.

SilverRed 5y ago

To be fair though, there are better and worse tools. There are legitimate reasons to say that PHP should be avoided and that Rust is a good choice. It's just important to understand how much weight these opinions have and understand why they apply. If you are building a bulk file rename tool, it doesn't matter how you do it as long as it works. If you are handling untrusted data from remote sources, then you may want to consider if C is a good idea.

Flex247A 5y ago
I agree with your points completely. Some tools are just better designed. I was talking about the premature opinions I had on these tools before I had even used them, or seen them in action. This is a problem as it limits my teamworking capabilities. For example, I decided to do the first year programming project all by myself as I thought nobody else could do it. Edit: added an example
moksly 5y ago
I have a somewhat funny anecdote on this. One of our sister cities had a tool for handling city-water or something along those lines, that was build in ASP Web-forms. All the city engineers were perfectly happy with it, but the developers behind it were worried that ASP web forms were becoming obsolete. Not really an illegitimate concern I supposed, but what they did was hire a company to rebuild it in AngularJS. So now they have a technology nobody else uses around here, while web forms simply turtles on because of how much legacy it has in various places that aren’t upgrading it.

dmos62 5y ago

To have access to (or sense to use) better tools for given task is good. To be smug about it is bad. Actually, drop everything about technology in this discussion: being prideful is just bad.

moksly 5y ago

Good for you! I think one of the more important lessons is to realise that the programming community can be very disconnected from reality. This is especially true for HN with its heavy focus on “interesting”. Judging by HN, things like Erlang, Rust and previously Go, would see a lot of attention and so would the Kubernetes way of doing CI/CD. Interestingly there hasn’t been a single Rust, Erlang or Go job offering available in the region of the world where I live since I started tracking them out of interest after a similar discussion on HN in 2019. There are however a constant demand for JAVA, C# and PHP developers. Because that’s the languages that are used in my region of the world, and as interesting as something like Rust might be, you’d have a hard time actually finding a job working with it. Even JavaScript isn’t that outspread here, if what you’re after is a full-time JavaScript job, because there is almost always a JAVA, C# or PHP backend to go along with it. You can of course find C++ job, there aren’t many, but there are some and I’m sure some of those places actually use Rust behind the scenes, but they don’t advertise it. Anyway, I think my point is that there can be a big disconnect between HN and what you’re actually going to end up working with, and you’re likely not going to work with just one toolset for your entire career either. Before I became a manager, I spent almost a decade working mainly with .Net, but with the rise of things like Azure Services I stated working more and more with Python and Powershell, these days I almost exclusively work with Python as I’m mostly handling data for BI or management purposes and let the programming get done by my developers. We have recently picked up PHP though, which you likely wouldn’t think would happen in 2021 if you go by how dead PHP is supposed to be. Well, it so happened that there is a big open source project in my country that utilises Drupal to create a “forms generating” CMS system, that we want to be capable of building modules for, which means we needed someone to learn PHP. Another really valuable lesson in humility I learned, and it took me years to do so, is related to the arrogance many software developers adopt when we get into the real world and start building things with the business side. Because our skill-set is so linked to dissecting and understanding problems, some of us adopt the unfortunate habit of thing we know... well everything. I’ve been arrogant enough to think I understood how our payment business process worked better than our director of payments, and of course I didn’t, but it was just so used to handling problems that I though I did. If you can, do better than me and apply your humility to everything, not just tool chains.

5y ago

lstamour 5y ago

I wouldn't say the primary takeaway from this post is to remind programmers to be humble. It's a takeaway, yes. But humility comes and goes, and reminders often take the form of bugs in your code that you didn't expect. I would argue the post is primarily about complexity, and in school you probably haven't seen how complex software can get because most projects have to be started and finished within two to three months. Once you start working, you'll quickly discover that the complexity of existing systems can be overwhelming, but this is normal. After 3-6 months working on a complex codebase, ideally with a team to help you, you'll have some idea of how the complex system works, and even if that idea is wrong (in many, many places), it will help guide future changes to the system. The point then, of reminding programmers to have humility, is less about hearsay on the internet and more about the need for tools and languages to make life easier for the individual programmer trying to read the code, then plan, make and deploy changes to a live system. If you're lucky, you'll feel like the system makes sense but changes too quickly. If you're unlucky, the system will make little sense and it'll be entirely your job to fix it or put up with it. Usually, hopefully, there's a middle-ground, where the system works well enough you don't have to make changes, but you're probably not entirely satisfied with it either. Humility can also be the reminder that just because a system looks broken (to you) doesn't mean it needs fixing right this second. If you can spare the time, it's almost always better to try and understand an existing system's quirks before you set out to redesign it and end up re-implementing some of the same quirks yourself. I'll echo mentions elsewhere in this thread and suggest John Ousterhout's A Philosophy of Software Design as a good book on the subject of complexity and API design, but to newcomers to the field, I'll leave the warning that it doesn't cover TDD as much as it could and it also doesn't cover modern Scrum/Agile practices and how development fits in with product design and company goals. But I still highly recommend it.

lstamour 5y ago
I also recommend listening to podcasts like Changelog[1] in which developers are talking through how they approach problems etc., and trying to back up what you don't understand online by watching YouTube conference talks, ideally ones with examples in them from the real world. Usenix talks, for example, tend to cover a lot of real-world engineering-at-scale challenges. The more you hear how programmers often make mistakes, the more the lessons around humility will sink in. :) [1]: Re. changelog, and the subject of both mistakes and TDD, https://changelog.com/gotime/174 https://changelog.com/gotime/174 was a great listen also. Testing has gone from niche to mainstream back to "the best projects do it, but maybe only when forced," and it's interesting to listen to modern takes on what to test and when.

goto11 5y ago

Lots of programming wars is just tribalism. Java is disliked on HN because it represent "enterprise" - big long-lived organizations which maintain a codebase for decades and therefore conservative. A different tribe than the startup tribe HN represent. Java is not in particular more verbose than say C or Rust for solving the same task, it is just a random slight on the language of a different tribe. HN is a great community, but it has a very narrow perspective on the world. As a beginner it is fine to chose to master one language first, but in the long run you should not "choose a language", but rater learn to learn any language, and understand they all have their strength and weaknesses. But there are so many choices of tools and technology in this industry and it is impossible to learn it all. Tribalism makes the world simpler because it narrows your perspective.

deleted 5y ago
[deleted]
internetslave 5y ago
Java is miserable to write. You don’t realize this until you work with other languages. It was literally built with guardrails to keep enterprise coders from getting too creative
- podunkPDX 5y ago
  I can’t speak to the actual act of Java development, but I can speak to Java applications from a sysadmin perspective (15 yr Sr. QA Engineer to a 3 yr Linux admin (don’t ask)) — I’ve got no real beef with Java from the development side, but maintaining some of those stacks in production is pure pain.
  - lmm 5y ago
    Huh? Java is probably the least demanding stack from the sysadmin side - no big chains of library dependencies, no docker, strong backwards compatibility that means you can fearlessly upgrade the language. All you have to do is keep an up-to-date JVM installed on your servers and deploy single-file fat JARs to them.

TeMPOraL 5y ago

The flip side of having "premature opinions" is that, at the very least, you gained a lot of data points early on :). It's kind of like with assembling a tricky 1000-piece jigsaw puzzle. You assemble the frame first (like everyone always does), and wonder how to fill it in. You could pick the most obvious feature on the reference picture, start there and focus on expanding it piece by piece until the picture is done. But what I imagine most people do is first speculatively placing all the pieces that seem trivial to match to corresponding picture features, in order to reduce the number of unplaced pieces quickly, and give themselves lots of starting points to expand their solution in parallel. This approach is useful despite it commonly turning out later that some of such early starting points are placed completely wrong - puzzle blobs get easier to position correctly once they grow in size. It's a long way of saying, if you keep track of confidence levels of your beliefs, instead of taking everything you read on the Internet as certain, even off-hand remarks on HN can be useful in navigating the enormous space of technologies and philosophies that form the software industry.

daptaq 5y ago

> the right operating system, the right text editor (vim), and the right window manager (i3). As a TA I see a lot of people who also made these same decisions, maybe just add Arch Linux and zsh to complete the cliche. So you don't have tl worry, as this is actually relativly commom. But I don't think it is wrong to have intuitions based on stories, as long as these don't prevent you from trying out said tools or languaged yourself. They can be right, but they might also be outdated. Just stay curious.

Flex247A 5y ago
Curiosity is what caused me to frequent HN :)
Agentlien 5y ago
I find this interesting because I've always been suspicious of anything hailed as the next big thing and obvious right choice. I've deliberately tried a lot of alternatives. And yet, after many years, as I've finally stabilized on a set of tools and workflows I feel really works for me, it happens to include Vim and Zsh. Of all the programming languages I've used the one I've enjoyed the most is indeed Rust. I have even come to really enjoy Unity after ending up at a company which uses it.
- daptaq 5y ago
  One thing is if you tried out different things and decide to use whatever tools you like, the other thing is seeing people use, eg. vim and just copying it without understanding why. The reason this perplexes me is that so many people end up with a working but ineffective workflow, for no real reason.
  - Agentlien 5y ago
    I know precisely what you mean. I've seen a few posts from people about how they finally transitioned away from Vim (or C++, or ...) after many months and then detail a long list of its flaws, all of which showcasing that they did not try to actually learn Vim, but rather try to work around it being Vim. It's a bit different from other tools and if it's not your cup of tea that's perfectly understandable. But why would you torture yourself like that if you're not willing to give it a fair chance? Edit: there are of course also those who do give it a shot, do learn the Vim way™, and then conclude it's not for them. That's great, I have no problem with that.

ChrisMarshallNY 5y ago

Rust is a good choice. It will serve you well. In my experience, I can learn a new language (and general style) serviceably well, in just a few weeks, but it can take years to learn the language in-depth, with the language being a “moving target,” as it evolves. I decided to specialize in Swift, and still have a lot to learn (I’ve been programming in Swift since the day it was announced, in 2014). Part of the reason for the time it’s taking, is because I have been using it to ship products, which slows exploration and research. What really takes time, is platform SDKs and frameworks. They can be real rabbitholes, with all kinds of idiosyncrasies and caveats. They, too, are generally “moving targets.” Good luck in your endeavors. I really enjoy programming.

chriswarbo 5y ago

> Even though I didn't understand their arguments, I still believed what they said, because I thought they were experienced, so they must be right. Even though I hadn't used the tools personally, I started developing premature opinions on them > This made me arrogant, because I saw myself as above my classmates As others have said, "good" and "bad" depend on the use-case; everything has pros and cons; but some things are still objectively better than others (e.g. if tool A supports more data formats than tool B, whilst being just as fast, just as secure, just as supported, etc. then A is a "Pareto improvement" over B; there is no reason to choose B for a new project). Whilst it's common to explain why something is "bad" (e.g. PHP encourages 'stringly typed programming', which makes SQL injection and cross-site-scripting vulnerabilities more likely); it's also important to explain why such "bad" tools are nevertheless widely used. For example, PHP is widely supported by free/cheap web hosts, is easy to set up (just copy a .php file to the server) and run (the URL is the .php file's path); it runs concurrently without needing shared state/threading/etc.; it has a built-in Web framework ('$_GET', '$_POST', 'echo', etc.); it can be embedded inside HTML files; and so on. This all helped it grow a large community in the Web 2.0 days, and lead to useful applications like Wordpress and MediaWiki, whose 'plugins' got many people into programming. This community of pragmatic (but often inexperienced) developers and their ability to quickly churn out Web apps has sustained itself to today; whilst the developers have matured, applications/libraries/frameworks have grown much more complex, the demands on the language are more diverse, and the language maintainers add new features and fix some of the language's underlying problems. I still consider PHP to be a particularly bad language, and would need an incredibly compelling reason to choose it for new project. Yet I know there are many reasons why people have chosen it, and continue to do so. Those aren't necessarily "pros" for the language, e.g. it often comes down to historical inertia and 'what we know', which is much less important for those just starting out, or working in a different field (e.g. data scientists), or facing a different context (e.g. Web apps implemented client-side, fetching data from managed cloud services). If we see the arguments against, but don't know much of the context or reasons things still get used, it's easy to make the assumption that others made bad choices due to ignorance. I think this is similar to Chesterton's Fence https://en.wiktionary.org/wiki/Chesterton%27s_fence https://en.wiktionary.org/wiki/Chesterton%27s_fence i.e. we should understand the reasons why someone did things in a particular way before we scoff at their poor life choices (after all, sometimes those reasons make it even more hilarious!).

golergka 5y ago

> Java is verbose, so it must be avoided, PHP is inelegant etc I think that these opinions are mostly correct, but you and anyone else would learn a lot if you chose to actually try Java and PHP and experience this verbosity and inelegancy first-hand, as opposed to just hearing about it.

deleted 5y ago

[deleted]

ChrisMarshallNY 5y ago

Personally, I dislike Java, and I never got good enough at it to develop any worthwhile opinions. That said, I really despise PHP, but spent 20 years, writing it, and doing a fairly good job, because it was the best tool to give me the results I needed. I feel that if we will use a tool, we need to take the time to become proficient with it. Here's an article that I reference fairly often. It's sort of a "reality check": https://veekaybee.github.io/2019/05/10/java8/ https://veekaybee.github.io/2019/05/10/java8/

denton-scratch 5y ago
"we need to take the time to become proficient with it." I have thought this for a long time. I have reckoned that it takes me at least six months full-time to come to grips with a new programming language (I'm 65 now, I learn slower, I'm retired, and I'll be damned if I'll learn any more). Over the years, I've worked in teams dominated by young whippersnappers who are very keen to learn the latest language/library/framework. But they don't allocate 6 months; they seem to think they can press their new tool into production after just 6 days' practice. The result was unsually unmaintainable code. I understand the motivation of the whippersnappers; they expect to change jobs within the next 6-12 months, and they want to be able to put the latest hot shit on their CV. But we ended up with systems that only a couple of people in the team could read, let alone maintain. Write Simple Code. Don't Be Clever.

commandlinefan 5y ago

> PHP is inelegant etc. ... who were still using 'inferior' tools Well... PHP is inelegant, and there's a reason that it's been abandoned. However, it's actually worthwhile to spend some time discovering that for yourself - if not about PHP per se, then about a different "blunt" tool. Part of the modern computer science discipline is working through exactly why so many simple-seeming solutions fall apart - it isn't obvious, and it's really important to internalize.

denton-scratch 5y ago
"Well... PHP is inelegant, and there's a reason that it's been abandoned." Abandoned? 79% of websites are still running on PHP. Let's postpone the funeral.

michaelgrafl 5y ago

Good for you. It's takes most people a lot longer to come to that realization.

bostonsre 5y ago

The more you learn, the more you grasp the massive quantity of knowledge that you don't have. You can't learn or improve if you think you know everything. I would say humility is the most important quality for an engineer to have if they want to be able to grow as an engineer. I've come across a small number of engineers that have lacked humility and acted as if they knew everything and they were a nightmare to work with. The first instinct they have when they approach most problems that they come across is that the issue can't possibly be caused by their code and you have to provide an unreasonable amount of evidence or a smoking gun to convince them to investigate their code. They design solutions as if they know the perfect way and they seem to lack empathy for users or others that may have to maintain that code.

smithza 5y ago

I am hopeful that you have misread the consensus that vim is most commonly used by those on HN... emacs is obviously the better choice and needs to be perceived as the best/most popular to keep the community active :)

axguscbklp 5y ago

Hacker News shows me the "Gell-Mann Amnesia effect" quite vividly. When people here discuss topics that I know a lot about, I often quickly realize that more than half of the people commenting are saying nonsense. When people here discuss topics that I know little about, I am often impressed by the jargon and tone of utter conviction.

kodah 5y ago

You sound a lot like me in the early parts of my career. Strong opinions are worth something when you're just getting started out, I can't quantify what they're worth but they do something beneficial in terms of speed. The downside is that anyone with perspective on their side is probably laughing (maybe giggling) at your strong opinions. If your journey is anything like mine you will end up driving yourself lower and lower into the stack until you wear yourself out. Ideological buoyancy will take over and you'll float somewhere higher, but you'll be much more knowledgeable and valuable as a result. All that to say, don't be too hard on yourself.

ozim 5y ago

I think that important part is "opinions also gave a feeling of security". I see it all the time in my daily life, people are insecure and mostly want some confirmation that choices they made are good ones. They buy a car and then they start saying that other car brands are bad or breaking so easily. They cannot face the truth if their car turns out to be a crap. Seems totally like programming language bros, and some people cannot stand that in other language they could make more money. So what? There are probably people using that language that make less then them. I don't want to live such life, I want to make mistakes and pay for them if needed. Lots of choices are reversible or can be changed, be flexible.

nickd2001 5y ago

100% agree that humility is important. And realising that at young age is great :) However, with over 25 yrs dev experience, I do believe its true that Java is verbose (and some of its frameworks hideously so), and PHP is inelegant. Both languages have improved a lot over the years, thanks to a bunch of smart people working on them. Having now decided your opinions were premature, you may one day come to the same conclusion based on experience. Python, OTOH, well, that's a lot of fun. Has its issues, but, overall nice to develop with.