4 ms·

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

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.

gfodor 8y ago
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.
vtange 8y ago
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.
- arcticbull 8y ago
  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.
- lugg 8y ago
  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.

gfodor 8y ago

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.

vtange 8y ago

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.

arcticbull 8y ago
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.
lugg 8y ago
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.