Comment by gfodor | Hacker News Reader

Comment by gfodor | Hacker News Reader

I mean sure, if you have limitless time then feel free to learn a bunch of programming languages as well as everything else you could want to learn. But real humans have opportunity cost. If you are a software engineer, the time you spend on skill development can already cut across many, many dimensions. Additional programming languages is just one, and I'd argue a fairly narrow one after you've touched on a few key language paradigms.

What about:

- Architecture

- Software Delivery

- Networking

- Project management

- Interaction design

- Visual design

- Human factors/Social systems

- Graphics/Art (2D/3D)

- Market validation

- Sales & Marketing

- Business planning and finance

- Application domain knowledge

- Operations and Monitoring

- Data infrastructure

- Analytics

- Machine Learning

- Machine Vision

- Computer Graphics

- Simulation

- Game Engineering + Design

- Information Retrieval + Recommender Systems

- Embedded systems/Control theory

- Optimization

- Scientific Computing

I mean there is basically an endless list of areas you can reach into in the limited time you have time focused on skill development as a software engineer beyond "on the job" training. Building a strong, broad "stack" of skills seems like a good investment. Learning new programming languages is a niche within a niche depending on how expansive a scope you set for yourself as a person creating software for the world to use.

I would argue that for software engineers, the fields you mentioned would be adjacent fields, while other languages would give deeper insight into the tools of the very trade you're in.

In a time of people going for T-shaped careers, another language is deepening the vertical bar, while another field enriches the horizontal bar.

In that sense, learning a new language and learning a new field are complementary, but different in essence.

I don't think there's a binary state on if an area of study is adjacent or not, but a spectrum that is unique to the individual. Depending on your career goals, learning areas that don't directly contribute to the production or quality of the lines of code you write could be more "core" to your skills and non-adjacent compared to learning an esoteric programming language you may never even use to build something with.

Given the leverage developing software can have, and the ease to which it can be deployed globally, I err on the side of assuming that the breadth of skills that are "core" to a career which includes a focus on writing code to create software to be potentially quite broad.

I think I certainly take a generally unorthodox viewpoint in that I have a hard time swallowing the idea that a single person shouldn't be able to consider the skills to design, build, deploy, operate, and iterate on a single piece of domain-specific software as "core" to the job of being a software developer. 20 years ago, it was generally normal thing to do that, with a huge number of software tools (often shareware) developed by a single individual or 2-3 person teams. Today, its much rarer, perhaps except in a few domains like indie game development or open source infrastructure products/frameworks. Projects may start that way but it's generally assumed that when it becomes time to get serious, you need to staff up and delegate to specialized workers.

Even within the generally accepted scope of the domain of software development I find it hard to understand the justification for the separation between "front end" and "back end" engineering -- beyond the fact that the tools today have grown full of incidental complexity, making it hard to get the breadth of knowledge needed to be effective, it seems clear that a person building a single integrated system is going to build something different than a number of people building a system where Conways law informs the architecture due to specialization and communication boundaries.

Learning a new language doesn't necessarily deepen the vertical bar if the language cannot really be used to improve productivity/innovation on top of an engineer's current toolset. Learning TypeScript on top of Javascript can be thought of as vertical, but learning say Lua or C# on top of JS is probably better described as horizontal unless you're already intending to do some really specific desktop application.

Learning different concepts from other languages can make a big difference. For instance I learned about the value of composition over inheritance by learning Rust, then applied it to my life as an Objective-C developer (prior to Swift). It forces you to break out of your well tread paths, and take the best of other systems and fold it into yours.

Coming from a procedural dynamically typed language like PHP and then learning rust, clojure, and node JS. All have huge benefits.

Rust ownership and types system teach you about the freedom it affords you when reasoning about values in a system.

Clojure teaches you about separating state from logic and the benefit of keeping it at the edges of a system.

Nodejs teaches you about async and programming which is imo, as different as functional is to OO. The way you need to reason about things is very different. The non blocking needs teach you about what types of things are blocking and which are not.

I took all these lessons back to PHP and my systems are massively improved as a result.

Most of the PHP hate comes from people dealing with PHP code written by people who simply don't know how to program.

That is not a defense of PHP, it has many faults, but it's a language like any other. I have problems, big ones, with every language and ecosystem I've ever been exposed to. That doesn't detract from their benefits or the concepts they can teach you.

Also, it takes like 20-30 hours to get mediocre with a new standard library and syntax. You won't "learn the language" but you'll get a good feel for it.

Arguing time cost as a reason to avoid learning new languages is pretty weak when you're spending a career programming.

This is why we need practical immortality. There's just too much fun to be had.

learning rust might teach a javascript programmer a lot about performance that they can apply to their javascript. learning f# or rust might get a c programmer comfortable with ADTs which one can leverage in C with a little work. i do agree though that taking this too far can just be a waste of time. maybe pick up ONE new language outside of whatever domain you are currently in, see if you learn anything useful.

Reply on news.ycombinator.com