1. A company in your own country which got marketshare mostly because of legal reasons and government interference.
2. A company which got marketshare by building products that people loved all over the world, has the smartest people working for them and have generated more value than the vast majority of the companies that existed previously in the world combined.
I'd agree with the implication here, if it weren't for the fact that the company on #2 would be _legally compelled to spy on me or my countrymen at the whim of 3 letter agencies_.
That rubs some people, such as I, the wrong way. I wonder why :)
I think this kind of affirms the general opinion that Germany and many traditionally powerful European countries is doing poorly when it comes to modern tech. What went wrong with Germany and Europe? They used to be the front runners in tech once upon a time.
Maybe it's just, that the European law makers understand the risk of being are to transfer sensitive persona data into other legislations, and that a local registered company doesn't mean there are technical bounds.
I am not sure which exact incident you are after, but NSA, the largest operater of surveillance in Europe is American and GCHQ, the second alrgest, is British and also outside EU these days. But yes, there are some actions by European governments i condemn.
However as a European citizen I have ways to counter actions by a European government. By voting, by legal means etc. Into the US I have now range and the US has very little responsibility towards me. Laws protecting Americans or actions in America don't protect me as a foreigner.
That said: The court case here at hand was about the government being the (indirect) customer of that cloud. Thus it's their data amthey want to be protected from foreign governments.
If you store data in your own country with non-American companies you're protected by your country's judicial system. If you use an American company or American-based company you're subject to illegal spying from the NSA or extra-judicial warrants from the CLOUD Act (which compels Americans to apply American law outside the US).
How is citing one of biggest human crisis of last century against the same country which did it against their own citizens a cheap shot. It's totally relevant.
"European countries doing poorly when it comes to modern tech" has never been an opinion.
You're confused, and your petty vindictiveness is unmotivated. The EU as a space of commerce is not yours to do with as you wish. You have to follow rules and regulations just like our own companies have to. And if your country had not been engaging in espionage and sabotage then there would never have been a need for these "unfair" and "underhanded tactics".
> You have to follow rules and regulations just like our own companies have to
Which companies? Seriously though. Is there a reason the biggest EU software companies are the likes of SAP and Capgemini, or niche players like Spotify?
I mean, I'm not talking about the USA or China, even Russia has a more impressive tech sector.
Could it have something to do with various regulations?
If the goal was to stop US companies, the EU parliament wouldn't've thought that the US lived up to the requirements of the GDPR. They assumed they did until courts struck it down
LOL, they never were. Germans are conservative. Try to pay by card in a shop/restaurant outside bigger German city. Either not possible, cash only, or you can use some local EC card, which only Germans are using. Rest of EU is using Visa / Master card.
But when is about TikTok I see most americans have completely different values, no sorry americans are consistent, only US citizens deserve rights, the rest can be spied on, tortured,killed etc. Give EU citizens same privacy rights and there so no need to start an economic war because some NSA fat and lazy agent does not want to prepare a file to request a warrant. If you are at it, maybe is tiem to let US citizens that killed people(like in car crashes abroad) to get their fair trial and punishment too.
We have rights too, you are not more special and deserve more basic human rights because citizenship.
I'm not sure what you're saying. Do you mean that each individual is supposed to know where every site is based instead of having country-wide/EU-wide protections in place?
Individuals are not perfectly capable of this decision, especially since they are multiple steps removed from said decision (e.g. saas I use is using another service hosted on amazon); and in a lot of the cases (e.g. using a software for their job) not even in a place where they can make the decision.
Government does not tell you where you should keep your data. They tell, where you can't.
This is because it is not a compliant place to store data at. Same reason we don't want you to store data in china, for example.
So you say nobody should say visit US because human rights apply only for citizens? Do I also don't have the right to point that this is bad? When did non US people lost this right to complain?
Is there a reason why making it illegal for NSA and CIA to spy on EU citizens with warrants is affecting you personally? Do you work for CIA and you don't want to fill paperwork?
This is such an obvious solution, remove the stupid law and partner with EU in protecting privacy, then you can work together against China.
All I am saying is Individuals are perfectly capable of making that decision. Whether they should store their data in Germany, California or some random Caribbean island.
Why does large-scale corporate IP theft matter? Well, for one thing, I can't imagine the next Neato being willing to invest in all that R&D if a chinese company is going to rip it off and sell it for peanuts, just so the internet can say "wow, this chinese product is amazing, and I don't know why corporate IP theft matters!"
The risk of someone ripping off your idea, designs, etc. has always existed, exists now more than ever with the internet, yet it doesn’t seem to stop people with ideas from trying to take those ideas to fruition.
I’ve never talked to any rational person with an idea they were passionate about who said they weren’t interested in continuing with it because someone else might steal it.
Then you've never talked to any VC or angel investor.
A primary concern of any investor is whether you have a defensible 'moat" for your product or service - can you make something that will then have a high barrier to entry of competitors.
If you cannot articulate how you will have reasonably solid protection from patents. copyright, or trade secret practices, good luck getting investment.
Your only strategy will be to somehow make & stock ready to ship as much of your easily copied product as you can before promoting it, and hope your promotion, marketing, and initial sales are a huge hit BEFORE some Chinese rip-off artist starts marketing it on AliBaba in single-digit days. I've read of cases where people had their product literally found for sale on Chinese sites before their first marketing & customer shipments started, because the design was ripped off from the factory.
The only reason engineers in the US adopted "clean rooms" was to circumvent copyright law, not because they simply weren't willing to copy IP from their competitors. US companies still invested heavily in R&D. Maybe Chinese companies will do the same?
It's a free market. There are plenty of companies investing in R&D even after knowing that there is the possibility of copyright infringement. There is still a huge upside in developing these tech.
The companies knew that copyright infringement is a possibility when developing the tech. They knew the reward was still worth it despite of that.
I am not getting anything designing work for you. On the other hand I can launch my own side projects. I know that if they are any good people are going to copy and start rip offs. I am willing to take that risk.
> This means companies are being pushed to build more efficient things.
No, this means companies are being pushed to build the least expensive things, efficiency is just coincidental in some cases.
> Humans will fix sustainability issues automatically.
That depends, if you mean "eventually" I can somewhat agree with the argument but that's just a wishful thinking thought exercise. Eventually sustainability issues will be fixed because if not everyone will eventually die from the lack of resources, doesn't mean that the fixes are timely or with the least suffering that we as a species could be capable of.
> No, this means companies are being pushed to build the least expensive things
Least expensive literally translate to more efficeny. To build cheaper things you need to spend less on electricity for manufacturing, less on transport (fuel), less on labor etc. Which means more efficeny.
> Eventually sustainability issues will be fixed because if not everyone will eventually die from the lack of resources, doesn't mean that the fixes are timely or with the least suffering that we as a species could be capable
Sure. But this also assumes we are on the verge of collapsing because of sustainability issues. We don't know that. This also assumes somehow if we start pushing on sustainability now we are going to overcome that. We don't know that.
> Least expensive literally translate to more efficeny. To build cheaper things you need to spend less on electricity for manufacturing, less on transport (fuel), less on labor etc. Which means more efficeny.
You are just considering the production aspect of efficiency. Cheaper is not higher quality, cheaper goods have a higher rate of failure, higher rate of failure means increased consumption which pushes production up. More efficient and cheaper production with better quality definitely falls into your argument, anything else becomes highly variable if it will translate, ultimately, to better efficiency of resource usage overall.
> Sure. But this also assumes we are on the verge of collapsing because of sustainability issues. We don't know that. This also assumes somehow if we start pushing on sustainability now we are going to overcome that. We don't know that.
Why on the verge? I'm using the same time-scale as you did: eventually, which in mathematical terms would mean a function with its time component using a limit approaching infinity. Eventually automatically solving sustainability because "market forces" push towards efficiency doesn't mean that we should just accept that as a rule and that it's the best course of action given that we can actively model and predict if we should and could be more efficient and sustainable.
What's the argument against focusing on sustainability first? Hampering innovation and some warped sense of progress?
If you are passionate about building communities then build your own website. And use reddit to get traffic to the website. You have full autonomy. You make money.
> Some of them being Great Wall of China, Taj Mahal, Machu Pichu, Petra, etc.
See:
> Thus, the Lindy effect proposes the longer a period something has survived to exist or be used in the present, the longer its remaining life expectancy. Longevity implies a resistance to change, obsolescence or competition and greater odds of continued existence into the future.[2] Where the Lindy effect applies, mortality rate decreases with time.
Petra was abandoned and rediscovered in the 1800s and has really only emerged in the last 20 years as a destination, after being featured in Indiana Jones movie. Similarly Machu Picchu was abandoned and forgotten only to be rediscovered in 1909.
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.
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 dive into another tool I don't really know and the cycle would repeat ad nauseum. In hindsight, I've wasted so much time digging into tools that I've never used again.
I definitely learned some good lessons and recognized some patterns along the way, but I think the "just pick it up and learn it" attitude contributes to poor code quality in a commercial context since jobs usually time-box things. I'm a fan of picking something up that I can get expert feedback from, which there again, requires expertise.
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 make things better for your customers. But you have to balance that against becoming the guy who works on the unimportant projects. That's real bad. If there's growth potential for the forgotten app, you have to get buy-in from the business and not just sideline yourself away from the things people care about.
Often these tarpits were contractually mandated. One customer wants a particular integration, so a developer builds it, and it works for the customer and everything is fine until another customer comes along wanting a similar integration and now the original dev is gone.
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.
The value of any other stuff you learn other than solving problems has half life. If you can be paid extra for Cobol stuff for a decade or two, then why not use this opportunity and get up to speed in 2-3 years after that.
If you have just a bit of bad luck, you may have a carreer with no real deep involvement with anything, not even talking about the fact that the language is just one aspect of your productivity.
Refactoring old codebases into something nice to work on is comfy though. It’s basically what I do in the startup world I just use less niche languages.
Although I’d suspect there isn’t a lot of refactoring going on in some of those code bases you describe.
I think this is a healthy and productive career path. If you can identify when a dead codebase is about to become fertile, and how to clear the debris to support new development, you can make a lot of money, have a lot of fun, gain a lot of respect, receive a lot of autonomy.
You just don't want to be the person tasked with work that's only done because some contact got signed. Identifying the difference is hard.
> Coming from web dev, I used to volunteer to dive into a Objective C repo to fix some random bug in a mobile app
The thing about this is that this isn't just a language change, this is an ecosystem change. It's one thing to go from writing Python based web apps to Ruby based ones, because web dev has a lot of concepts that will apply no matter the language. Objective C might be something you can pick up no problem, but having the learn all about mobile development and that ecosystem is a much larger task, and I could absolutely see that getting exhausting if you're hopping from web, to mobile, to desktop, to embedded, etc.
Ecosystem switching requires a lot more of a knowledge shift than just a language does, IMO.
I'd agree with that. I even think the difference between frontend JS development and backend JS development is bigger than, say, backend Java and JS development. But managers, even ones with tech backgrounds, tend to assume the language is the key skill.
A good developer should be able to master a couple of different ecosystems given enough time but expecting them to constantly jump between them is never going to lead to great results.
How do you switch languages during a job search? Are you avoiding companies with language requirements (four years Ruby)? Do you run into language/framework tests and/or homework assignments in languages you are unfamiliar with?
I've interviewed at probably 15+ companies over the last decade, and none of them had language requirements or tests. Honestly I see those things as red flags. If you can find somebody with good problem solving skills and proficiency in any language, they'll be able to pick up your language no problem.
"they'll be able to pick up your language no problem."
That still takes time. If someone is already experienced in an (complex) ecosystem, he or she will be way more effective in it, than someone who has just general skills. I guess I am a very good problem solver. But if I suddenly would have to do a C++ project with all its footguns, I am not aware of (last time I coded in C++ was in university)? I would suck in it for quite a while. This would not be effective at all, unless I would want to change my skillset to the C++ ecosystem.
I'm guessing that's not typical for most devs and most job openings. Recruiters in particular seem to assume they need to find devs experienced with particular stacks, and for companies who need to quickly re-fill roles after losing staff, a good dev with experience in the stack/ecosystem you've been working with is always going to get up to speed faster than one without that experience. I'd also say convincing hiring managers that specific libraries/ platforms/languages/tools that you've been using shouldn't be listed as "must have"'s in a JD is hard.
I'm not sure. I'd guess very few companies that hire more than 20 devs a year would have any language requirements. But I don't know what % of jobs are at companies of that size.
In my own city I'm not sure there are any such companies. But I was involved in helping out with a hiring round for Thales recently that were looking for 15 devs. They had very strong language requirements.
I prefer companies which are open about the technologies and languages I'm experienced with. That's a huge green flag, that they consider their software engineers as smart people solving hard problems while continuously learning new skills. It also means they listen to their senior technical staff, which consider that learning new bits of stacks is hardly the most complicated thing they expect you to do.
As opposed to companies which consider them as glorified factory workers, who are insufferably hard to manage and monitor.
I'm currently working with RoR, which I'd never used before, and what matters is that I know algorithms, SQL beyond ORM, how to write code which won't be a nightmare to maintain in a couple of years, etc. All those skills are the same in Rails, in Django, in C++.
Does anyone still have language requirements? I did my Google interviews in Perl and wrote mostly Java and Go there. At my current job, our codebase is all Go (expect frontend) and pretty much nobody we hire has prior Go experience.
Prior experience is almost a curse these days. I learned Go by having the Go team review every one of my CLs for a year. Now I do Go code reviews and think "that simply isn't done, I would never have been allowed to check that in", but often have a hard time supporting my arguments. (When Effective Go, Code Review Comments, and Test Comments fail me, I usually resort to snippets from the standard library. "This pattern appears 0 times in the standard library, I don't think we should use it." It's a lot of work, but I will say that a few things I thought were simply never done are actually done. And that's my standard; I hate it, but Go itself did it to implement Go, so you can too.)
Side rant: I guess the Go team stopped doing this. Read Kubernetes for the current state of Go at Google. Wow.
It's easy to trick recruiters about tech stack ("We require someone with 5 years of experience in Django". Me: "Sure, I'm qualified"... While in reality I have over 6 years of experience in RoR and I have probably used Django in one side project). The moment you pass the screening part, then it comes the part when you judge your future/potential team: do they care about good engineers or good django engineers? Usually, it's the former.
Having done the merry go round of different languages, it also feels great gaining expertise in an individual language and to utilize new (release) capabilities of that the language.
Absolutely. Conversely, it's frustrating to deal with a build and release system that's subpar compared to what you're used to working with, but I recognize some folks probably feel that way about my preferred tools. That's just where I've chosen to invest my time I guess.
I was shocked at how hellish compiling and releasing a large iOS app was compared to deploying a web service, not to mention setting up the development environment and installing dependencies.
Yep, if I never have to deal with an automated CI/CD pipeline for iOS again (especially trying to reliably run unit tests - the simulator is flaky as hell) I'll be very happy. I don't even mind the MacOS-only requirement so much (though it does suck), but Apple's tendency to constantly force breaking changes on you is just an endless source of pain (by force I mean, release to App Store not permitted unless you build with version X of Xcode, which requires version Y of MacOS which is incompatible with version just-about-anything-else or everything else you're using.)
> I've wasted so much time digging into tools that I've never used again.
Don’t think of it this way. Learning new tools is almost never a waste of time, you just don’t know when you’ll need the lessons learned next. But you will.
Maybe it's counterintuitive, but I think the "jack of all trades" role should be given to someone who's very senior, but isn't focused on career advancement.
It sounds like you got stuck learning more trivial things before you had a good foundation in something more substantial (like C or UNIX).
If it weren't for the rampant ageism in the industry, that job might be a perfect fit for someone in their 60s who has already written a few million lines of C and is happy to help less experienced people just get unblocked.
Instead it often falls to the "junior senior" because the "senior seniors" are all pushing 30 and need to work on portable skills.
(Just my observation of the industry, maybe your own case was different.)
I've found a lot more career happiness with focusing on a long-term domain (networking), long-term expertise (testing), and a stable tech stack (python, c, etc). Got pretty close to burnout chasing the latest libraries in the latest languages a few years ago but now I'm very happy making sure the product is cutting edge but the tech stack is stable.
This is what I'm trying to do as well now (move from full stack web dev to something more in the lines of what you're describing). Any tips you can remember on how to make the move?
I spent a bit of time practicing these tech stacks in my own time and fitting them into prior jobs where I could, but honestly it’s worth just getting out there and applying.
As a fellow webpack victim, the new way of bundling things in FE is esbuild and it's better in every way - faster, simpler to configure, easier to understand... and did I mention faster? my god it's so much faster.
Your point about wasting your finite life dealing with webpack still stands, but just want everyone to know that there is a ray of light in frontend.
It depends. Maybe the alternative is to get better at a tool you already know. Maybe you can be a jack of all trades, master of none, or you can go really deep into only 2-3 things. It depends a lot on your personality I think.
Your first sentence is correct. Your second sentence would be better revised to "Explain the problem and the fact that the client will be signing on for a long timeline and high level of schedule-risk. Then work at a pace which does not damage your mental health."
I can't tell you how often a huge and expensive Oracle DB app design project turned into just emailing spreadsheets instead... That would get me fired.. -Senior Developers Everwhere. :P
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.
Obviously some languages demands greater knowledge (e.g. C, Haskell) to master and use appropriately but they are a minority.
I strongly disagree. It's very visible when someone is trying to write (eg) Python in C++ or vice versa, in a way that can substantially harm readability.
Yeah I agree. I know growing and learning is the job. But how much am I going to use X in the future? I did one project in PHP. Just enough to learn I don't really like working in PHP. Is a few months of PHP experience useful in later job searches?
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 perform worse until you become an expert at them (which is unlikely for anything more than a handful of languages and even that requires working with them regularly).
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 make.
Edit: This does require a certain persona in the space of "reasonably good dev". People who have spent their entire life focusing on a single language or paradigm are a lot less likely to be able to shift gears. People who have broad exposure to different concepts are more able to say "How do I do X in Y?" and stop fighting their new language.
I've seen huge differences in productivity between people who've been working with a given stack with for years vs months.
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 < 6 months experience with the tech stack. And the jr dev (who was an inferior dev in general) blew them out of the water because of the tech stack experience.
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.
What sort of time are we talking about on these projects? If you're looking at something that has to be done in a few weeks, sure. In a normal role where I expect the person to stick around for a couple of years I'll take the person with better overall skills every day.
In your example it the answer may be “none”, but I’d be curious of the amount of tech debt that may have been introduced by the jr vs the sr’s; whether or not sr’s had better intuition.
Yes. Lately I’ve found this to be true at my job, with the whole frontend/backend distinction.
Job specialization is good. I mostly write TypeScript, and I can usually contribute the most value to the company by writing TypeScript and sticking to frontend things. Sometimes though, the fastest way to solve a problem is for me to dive into the backend, and I have no qualms with doing so.
Some people on my team treat the “other side” as totally foreign, however. This leads to willful ignorance and glaring inefficiencies. For example, someone asked my senior frontend teammate a question, and the answer could be found trivially by someone with an inkling of backend knowledge. Yet, this person threw up their hands and dragged a backender into the conversation because they couldn’t be bothered to learn a single thing about the backend in the 5 years they’ve been with the company.
Please just be a problem solver. Don’t be just a “backender”, and definitely don’t be just a “Nim developer”.
No the best strategy is to memorize leetcode problems. All the highest paying jobs (>400k) require dictionary like recall of computer science algorithm fundamentals.
Well certainly not all but that strategy, if you can pull it off, will probably get you a very high-paying job and maybe you won't have to work so hard.
But that's not at all what the OP asked for. Maybe they're already making >400K slinging JS at Facebook or Google. Lots of people do!
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.
The latest LTS version is JDK17 (e.g. records and switch expressions) and has been for long enough to be production ready. I reckon half of the people on this forum didn't even work in software when JDK8 was released.
Yes, Kotlin/Scala would stop driving you crazy. No, I don't see nearly enough Bay Area companies deprecating Java in their favor for new services :( They are probably betting on the next LTS to come soon enough (with pattern matching and hopefully Loom).
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
This on the surface sounds solid but I persobally think most job searches are narrow unless you are doing “career changing” moves. How many good UI/UX colleagues do you have that are good at anything else? How many compiler developers can center a div on the page? I think this “I know a lot of things” is just something we say - terms like “full stack” developer etc…
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
If you make in a month what others do in a year, you can retire after 6-8 years and never worry about having to find another job if you play your cards right.
Accounting for taxes and moderate expenses, at the end you should be sitting on close to 2m USD. That's more money than the vast majority of people make in their lifetime (after taxes). If you don't plan to live to a hundred you'll be fine even if you don't do any higher-risky investing, slowly spending it.
Expecting a 12x of median industry rate via specialization is not realistic. I'm sure such outliers exist and you possibly know both of them but this is not an actionable advice.
It's a cute theory, but the reality is most employers want you to be relatively efficient from day dot.
I work in a team with a codebase split 50/50 between C# and C++, and if you're not proficient in one of those then the chances of you getting hired, even if you're an incredible programmer, are slim.
This is a trait of an employer that I consider a red flag. If they don't understand that most programming languages are pretty similar, and can be picked up quickly by any willing person, they probably don't understand a lot of other things in regards to tech
That's not fair. The whole point of "footguns" is that they are not obvious and that the reason more experienced people don't set them off, is because they've directly experienced their results before.
Our industry went to the trouble of inventing a whole new language (Rust), which is now being championed by major industry players, because those footguns are so non-obvious. "Trusting" smart people to "just not make mistakes with pointers" was clearly the wrong choice.
If you haven't used C and C++ before, it's reasonable to think you're going to make those first-time mistakes with your code inside their codebase. That's a good argument for not hiring you and only hiring experienced C/C++ programmers.
In practice, that's exactly what those companies do.
Depends a lot on what type of software is b ing written. The people that keep beating the drums that Java = C# have not worked with the language extensively enough. So many things outside of basic languages constructs are different. Tooling is also a big hurdle to change too.
I've worked in both extensively, and there are certainly far more similarities than differences. I've put C# devs on to Java codebases and got them up to speed very quickly. But you still need to have Java pros that know all the gotchas etc. to do the code reviews.
The reality is that today's job market is not ten-years-ago market.
Employers and companies can't find enough developers to satisfy the demand.
They should provide a bit of wiggle room and train internally as well. Three months getting into a new language/framework is not that much compared with the cost of hiring.
I read this advice so much as a younger programmer, but now I am in a position to say - this doesn't work.
Sure think of yourself as multi-lingual and able to learn anything (which you probably are). But don't market yourself that way, especially if you're a contractor. People want someone who knows their tech stack and they want you to be productive yesterday.
> 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.
I'm not sure becoming a high paying/good software engineer are necessarily relevant to the stated goals of the OP's question. There can be inherent reward in working with a set of less popular, well crafted tools. Yes you might grow faster as a professional by working with a group of industry best JS programmers, but working with a small team building in Elixir and moving fast without ever hitting a NaN can be a pretty rewarding experience.
Although true for the job, this is a bit disingenuous for getting the job market because recruiters are absolutely not thinking of you as a problem solver with language being just one of the tools.
I don't think that strategy works best. Most of people I know that get paid very good amounts are specialists in a given framework or language, like knowing the ins and outs of PHP for example.
I rather say "be a generalist on the long term and a specialist on the short term".
This is all my opinion and comes from my personal experience, though. Take it with a grain of salt.
Knowing a language is helping you read/write the code in a good quality.
Knowing the ecosystem and solutions in this language is your sellingpoint.
Take any language and tell me one can be productive in no time without knowing the ecosystem around it.
Within our team we use 5 different mainstream languages to accomplish different goals within our system.
We handle a single service, but we manage the full stack using many different languages and frameworks.
We don't have to be expert in the frameworks, we just need to be experts at what we are building. And we learn each framework to the point where we can accomplish that.
The "selling point" that we value is to be able to deliver.
This attitude is a great starting point, but take caution to curate a future for yourself that you find interesting.
Whatever work you do, you will forever be the person who has done that work. Next time something needs to change in that domain or language, you might find yourself talked about as a specialist!
The moral is to choose and pick your projects carefully. Vocalizing your experiences with your manager goes a long way for shaping your future: like “I liked working in X and I want to do that more” and “I am glad I got to try Y, but I really didn’t enjoy it.”
This feels good intuitively but is not born out by my experiences and observations. The notion that "high paying/good software engineer" are two aspects of the same outcome is wrong. To the OP, the answer is "pays beter with less demand and more risk". Example: we're struggling to find Elixir developers and thus paying a premium for good (not great) talent; we're also looking to switch to Node which will reduce our demand for Elixir devs.
Seriously, pay the premium. You'll waste the delta endlessly searching through the chaff of node developers, and then pay another cost when your node architecture needs to be de-spaghettified or your node developer decides to create another layer of tech debt by switch to using next.js from redux, or starting to use aws lambdas, etc. Etc etc.
Agreed, there are definitely some langs that go out of their way to be overly complex, obscured, obtuse, and proprietary in nature that I totally avoid.
They can lead to what I call "rabbit hole" jobs, which make it very hard to change disciplines thereafter.
Now most recruiters, and even hiring managers, rarely have an idea of the nuances of development during the interviews I attend... Because usually their a buddy of executives within the company more often than being there for their capabilities or educational background. When the technical component comes, I also often get paired by another dev within the company, or a person with a technical grasp that's totally outside of what they know, so keeping my knowledge diverse, and being able to adapt to what I don't know is key in order to be worth a good salary.
Adapt and improvise, manage their expectations of you, but most importantly, know how problems get solved correctly. The tools used don't matter if the house built is well done.
Good luck with listing "problem solver" as a skill in your resume. I don't think anybody will care about it.
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.
Precisely. Any good company won't care what programming language you are specifically proficient in. They care about how proficient you are in learning new things.
I have created a lot of Nim projects and implemented much of its stdlib. My full-time job isn't using Nim, but the experience I gained through my work in Nim has helped my career significantly.
The keyword here is good. Even then, this isn’t largely true. It is quite hard to convince companies to hire for a skill that you already don’t have experience in. In most cases, there are gatekeepers - those lovely recruiters who don’t know the difference between a computer and a washing machine.
if you're optimising for those then you might as well learn whatever's most in-demand and popular, probably Python. There are plenty of companies that are good enough though, for most you won't even need to talk to a recruiter.
> 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.
Some languages contort and constrain your thinking in bad or silly ways.
> Thinking of yourselves as someone who is a writer of a certain programming language is self constarining and missing the point.
I find this view tends to lead to only using popular languages anyway because you don't seek out any specific language, so the effect of this belief itself is self-constraining.
yeah disagree - as a high-skill consultant coming in as a problem solver, I mostly got dirty jobs that no one wanted to touch. "Pay someone to do it!" you can hear the cries. The interesting and low-touch projects got grabbed quickly by insiders. Super-problem-solver was not a good strategy in practice. This profession has a long way to go in some respects.
This is very true but there's still is a very big difference between knowing languages like JS, Python, Ruby or Go but then jumping into a place that uses Elixir or a niche language that's different than a lot of other popular languages.
For example I took a position to do mostly infrastructure work. Most of their services are written in PHP which I haven't used since the early 2000s. I wouldn't classify myself as a PHP developer. Sometimes I find myself diving into the code to self-solve issues I have that are infrastructure related. My thought process is if I can solve a problem and it's within my scope of things to do I'd much rather just do it than add extra work to another developer on the team. In the worst case scenario someone with actual PHP experience who does the code review will offer suggestions to make the code better.
I don't really know PHP but I can look around and navigate the code without issues. There's nothing that looks too foreign and the code is easy to grep to find stuff. It's also not too bad to trace code in a large app and understand the logic. There's also a massive amount of Google results for almost any problem you can think of. It really means for a lot of cases you can combine previous experience and be productive in a similar language without really knowing it. Enough to contribute real code that gets shipped to production.
I ended up doing this yesterday where I added an IP whitelist address exempt config option to one of our apps. I wanted to at least toy with the idea of doing IP range detection within a CIDR block.
In Python this is really easy, the standard library has functions to do this with 1 line of code. Ruby's implementation is even easier and built into the language. For PHP I had to Google around but found a pretty small custom function to use in less than 2 minutes. For Elixir? Well you have to use a 4 year old+ third party dependency or dive down into Erlang and understand pattern matching and write a bunch of code to manually do the comparisons. Maybe there's a good Elixir solution but it wasn't on the first 3 pages of Google when searching for similar terms as I did for Python, Ruby and PHP. Weirdly enough if you search for "elixir check if ip address is in cidr block range" most of the top results are StackOverflow posts for other languages. There's no contest in comparing the amount of effort it took to get a solution.
I know this is 1 just example but I also know when I tried learning Elixir (and did end up writing about 10k lines of code of it) I kept running into situations that took half a day or longer to figure out while actively trying hard to learn and use the language. These problem could be fully solved in a production ready way in 5-10 minutes with Python or Ruby (and I guess PHP too) either by knowing how to solve it in an imperative way or finding nearly a perfect solution when Googling that's digestible enough to where you can fully understand it and apply it back to your problem.
> For Elixir? Well you have to use a 4 year old+ third party dependency
Can we please stop using “4 year old+” as a generally applicable rule to reject libraries?
I know “4 year old” seems like forever ago in Ruby or Node (I can’t talk about Python or PHP), but other ecosystems such as Go and Elixir take compatibility seriously and “4 year old” libraries most often just mean they are done: they work for their intended purposes and there are no breaking changes in the language or tooling forcing frivolous updates.
I have used 8 year old Erlang libraries in the past with no issues whatsoever.
Nope, I only looked up the Elixir solution for the sake of my reply here. I haven't worked with Elixir in like 9 months.
Based on the docs it says IP.Subnet.is_in only supports IPv4. The Python and Ruby solutions transparently support both. That kind of sums up my Elixir experience (ie. something might partially exist but to really use it will require a lot of extra work). It's also impressive at how infrequently the Elixir docs come up in Google searches. It's strange considering how many words are there and it's the official source of information for the language.
IP.subnet.is_in is a guard, so there are different constraints. You could still use the `in` keyword.
Honestly my experience with python has been "the solution you're looking for probably exists, but using it will require a lot of effort, and heaven help you if you need to debug someone else's code", but I have mostly dealt with Django which is a nightmare of hidden code and tensorflow. Maybe it's just I've worked with shitty python devs and on the other project Google's notoriously bad engineering practices in some of their public facing OS projects (angular, tf)
> IP.subnet.is_in is a guard, so there are different constraints. You could still use the `in` keyword.
Does that mean you can do something to make it transparently support IPv4 and IPv6 even though the docs mentions it only supports IPv4? Will it be more than 1 line of code?
> Honestly my experience with python has been "the solution you're looking for probably exists, but using it will require a lot of effort..."
I found it to be the opposite approach. The last time I wanted to increment a counter outside of a nested loop in Elixir it sprawled into a multi-week conversation with the author of Elixir, a git repo with 100+ programming language examples to solve the same problem[0] and a proposal on potentially altering Elixir itself to make this process a bit easier. The Python solution was about 2 minutes typing into my code editor and moving on with life.
I'm not saying either language is better than the other but there's certain things that can done a lot easier in Python and on the flip side I'm sure there's things you can do a lot easier in Elixir.
I found in practice for me personally when building typical web apps I kept running into roadblocks left and right with Elixir where as I never had these issues with Python or Ruby. That's why I stopped using Elixir.
> I have mostly dealt with Django which is a nightmare of hidden code
I think that'll happen with any big framework, especially if you haven't contributed a ton of code to it. The Rails code base can be intimidating too and Phoenix's code isn't any more approachable to someone who isn't already at the high end of expert with the language.
I mean to be quite honest I remember this problem and all I could think of was "this being hard is a sign that the data structure is poorly designed. But I also remember giving you a four line code sample using the process dictionary that you could have used, because this was "clearly an exceptionally pathologic data structure".
Oh yeah I remember your reply (not word for word but the approach of using it). If you search around for using process dictionary it seems to go against the grain of Elixir since it introduces mutable state which is fundamentally against what the language provides. It did lead to much easier to understand code because it brings the language more in line with how other languages work where you can update a variable outside of a specific scope. Maybe it's a good example of the idea of "sharp knives" but applied to Elixir instead of Ruby.
I don't think the data structure was that crazy or rare. It boiled down to looping over 2 lists and wanting to keep an independent count of each one.
tl:dr What do I do if I just want a job that I enjoy and do not care much about the money?
I do not need a high paying job for various reasons, but I still want(/need?) to do something fulfilling and wouldn't mind getting paid for it.
I like research. I have been doing academic research for the past few years, so I am still considering a PhD. I definitely do not have to worry about a high salary there! But I also like plain old solving problems with programming, so I am considering going out and getting a job as a programmer (again).
Since I don't care much about high pay, and I do care about enjoyment and self-fulfillment, it seems that I should be picky if I am going to look for jobs. I do not find fulfillment in high compensation, though I understand that others might. I would rather do something fun, interesting, or unusual, while avoiding features I already know I dislike.
For example, I learned OOP a bit in college during my first-ever programming course (Java). It didn't stick and all I learned was that I don't like OOP. Surely this suggests I should avoid jobs/languages that require an OOP paradigm?
Like, sometimes I think I should just go back and hardcore brush up on my C programming and go get a job writing C somewhere. Or see if I can translate my academic R/Python skills somewhere. Or go learn some functional language and see if I can get a job doing that.
> Thinking of yourselves as someone who is a writer of a certain programming language is self constarining and missing the point.
I totally get where you are coming from. For example, many people do jobs they dislike or don't care about knowing that it enables activities/experiences/purchases they do like or care about. But really, does this not fully depend on what each person subjectively thinks "the point" is?
The point for me is that I would like to enjoy all of my life, not hate my work time and only enjoy my leisure time.
1. A company in your own country which got marketshare mostly because of legal reasons and government interference.
2. A company which got marketshare by building products that people loved all over the world, has the smartest people working for them and have generated more value than the vast majority of the companies that existed previously in the world combined.