181–190 of 273 posts
Earlier quoted context omitted.
I think this is true, but writing code in certain languages (e.g. Java 8) drives me a bit crazy. It’s like running a race with your arms tied to your sides. I put certain languages in a general negatives bucket along with noisy offices, stack ranking, heavy process, etc.
> Java 8 drives me a bit crazy (whisper voice) kotlin
1. Not every shop will let you use it
2. Kotlin has a bunch of the same limitations.
Earlier quoted context omitted.
Could you share some more details? What kind of project is it? Did/do you hire your team who already knew Elixir, or did they learn on the job?
At my current company we’ve got 100+ engineers writing Elixir. Fintech in the US. Almost none of them know Elixir when hired.
Earlier quoted context omitted.
IMO the only way in this industry (without having your own company or something like that) to high-paying gigs is to become more valuable to a company than company is to you. and that you can accomplish only through DEEP specialization
The downside to this of course is the breadth of your next job search (should it come to that) suffers.
I mostly develop on a computer which isn’t connected to the internet (so no Google, Stackoverflow etc…) and I often think how miniscule fraction of “full stack” developers could perform even the most menial task in any of these “stacks” they apparently know
Earlier quoted context omitted.
The SO chart shows Erlang is actually highest at $120K salary. Also note the median years of experience is 13. Making $110K after 13 years is not all that great. The chart would be more useful if it showed a trajectory over time for each language. Overall I don’t think this chart should influence anyone’s decision to pick a programming language. I worked with a few teams using Clojure and there was nothing magical ab…
The problem is that learning a niche language like Clojure should demand a higher salary but it doesn't. Companies realize they can get an existing experienced developer to learn it. It's also not wise to jump ship to a niche language like this unless you really have the funding for it and even then, the talent pool is much smaller and you find yourself its not an employers market in that niche. So as a business owne…
Earlier quoted context omitted.
There are organizations that generate forgotten apps that are basically used but unmaintained. These are tarpits for developers. You don't want to be the person they fling at every forgotten codebase. They tend to be sideshows - if they really brought in the money, or the users, the business would invest in them and have people who know the language. There's value in being able to go in, fix a little problem, and mak…
I know from quite a few traditional corporations, especially banks that have very central old systems that they pay people enormous day rates to maintain. But the question would be if one wants to be the go to guy for keeping old cobol things running.
Earlier quoted context omitted.
Salaries in the eu is most def. Lower than us, but earning 100k with a couple years experience is pretty common in London/Berlin/Scandinavia etc. Biggest difference is that not a lot of people are earning 200k+ salaries in eu.
100k in Berlin is pretty extreme, Scandinavia and London I can see it more. I live in Hamburg and 100k is basically unheard of.
Best strategy for becoming a high paying/good software engineer would be to think of yourselves as problem solver and language as just one of the tool for problem solving. Thinking of yourselves as someone who is a writer of a certain programming language is self constarining and missing the point.
As an experiment, one can create two resumes with different identities where the first one is listing Nim as a skill and the other one is listing Java and Spring as skills, and apply to the same jobs. I wonder what the ratio of replies will be.
Earlier quoted context omitted.
I used to think this way and wound up completely exhausted in my career. Coming from web dev, I used to volunteer to dive into a Objective C repo to fix some random bug in a mobile app and then a week later my boss would ask me to build a big feature in that app. I'd spend a few weeks getting up to speed on the language and build the feature, and then I would never use what I learned again. My boss would ask me to di…
> contributes to poor code quality I have another perspective, I think code quality are pretty uniform across languages, either all of ones code quality is poor or it will be fine across all language one writes. Most of the code quality stems from logically dividing the building blocks and making it readable. Hence it should be logically traceable and uses the basics whenever possible. This is good, readable code. Ob…
Earlier quoted context omitted.
While the basic syntax is relatively easy, knowledge of APIs (whether standard or third-party libraries), design patterns and conventions takes time (and practice) to master regardless of skill level. Being an expert at a single general-purpose language will often make you more productive as you can focus on the business problem at hand rather than spreading yourself thin across different languages where you'll perfo…
Deep expertise isn't as useful day to day as we often portray. With a little elbow grease one can get to a place of being more than baseline productive in relatively short order. Depending on the language I expect a reasonably good dev to be able to be "fluent" in the range of a few weeks to a few months. And it's not like they'd be useless the entire time before that happens. To me, that's a reasonable investment to…
The quality just isn't even close. Recently I outsourced a project to two groups of people. A jr dev who had 2 years of experience but all of that experience was with the tech stack, and 2 sr devs (10 yrs experience) who had And honestly in terms of raw talent I think the sr devs were better, but it just didn't make up for the lack of tech stack experience.