5 ms·
My takeaway was that "software developer" is not a very useful job description anymore. CRUD, web dev, games, HPC, embedded and other fields require vastly diff
by l0b0 6y ago
My takeaway was that "software developer" is not a very useful job description anymore. CRUD, web dev, games, HPC, embedded and other fields require vastly different skill sets. Changing between these fields can be like starting your first job out of college, learning to use not just different tools but also focusing on very different priorities.
("$language developer" is only slightly more useful, especially for languages which are used across many different fields such as Python (web dev and science), C# (web dev and games), C (games and embedded), etc.)
The article revolves around the continuum from building everything yourself to importing a third party library whenever it can speed up delivering the current feature just a little bit. It's pretty clear by now that the many software development fields fall into different parts of that continuum.
- rtlfe 6y ago> Changing between these fields can be like starting your first job out of college I don't think that's true unless you've done a bad job at learning in your previous job. There are lots of thing you should be learning that aren't directly related to the domain of your code: how to debug existing codebases, how to read other people's code, how to do code review, general coding patterns, architecture principles, how to prioritize your work, how to work with other people, etc, etc, etc. All of my jobs have been in very different domains, but the experience at each has made me much better at the next.
- s1t5 6y agoSoftware developer is not a description, it's a title. It's okay if it doesn't perfectly indicate the domain and tech stack that you work with.
- rtlfe 6y ago> "$language developer" is only slightly more useful I would argue that this is not a useful distinction at all. Any good developer should be able to pick up any language quickly. At the companies where I've worked, even the interns have no expectation of knowing the language before they're hired, and the vast majority of them learn quickly enough to ship useful code within their ~3 month internship.
- kohtatsu 6y agoThey just meant in terms of "x language is typically used for tasks y, z". Of course you can do most all things in most all languages, but often times you can infer CRUD/web dev from PHP, for example, and would be far less likely to come across a PHP game developer.
- fractionalhare 6y ago> Any good developer should be able to pick up any language quickly. I see this repeated very often without support, and I think it should be challenged. In my experience there are cases where it's true, and cases where it isn't. Actual example: I have met highly competent software engineers who were (primarily) excellent Python programmers. They knew OOP well, they didn't typically over-abstract, but they could still leverage modular code for reusability, they tested early and often, they could dig into an existing codebase and maintain it, they could critically and constructively review others' code, they had a deep knowledge of the Python standard library and various domain-specific frameworks, etc. They were really good at all of this. But by their own admission, they were crap at C++. They didn't really know memory management at all, and they didn't really get the whole "ethos" of C++. Moreover, they periodically tried (and failed) at picking up functional programming. Now I believe if they were sufficiently motivated they could eventually pick these languages up. But they wouldn't "quickly" ramp up on a production codebase written in a C++ or Clojure. The idea that they're not a "good developer" because they wouldn't be able to quickly become productive in one of these radically different languages is therefore incongruous to me. I'm sure they could dive into a Ruby or JavaScript or even Java codebase. Or maybe C++ if it was strictly modern, 17+ and avoided raw pointers like the plague. But in general, no. It would take a lot of time, because some languages come with a lot of baggage that aren't just about the syntax. For someone who had always relied on Python's PIP, for example, the process of vendoring and importing C++ header libraries is already an obstacle. The reason I'm going on about this is because it seems like received wisdom and is often stated as an accepted aside, but I really think it needs more nuance. Otherwise we run the risk of defining "good" software engineers by what is perhaps just a no true scotsman.
- rtlfe 6y ago