For the people I work with, I'd say no to writing more efficient code, and maybe to using more advanced algorithms. I say maybe only because they'll just ask an LLM to make it more memory efficient. Which in theory will cause the LLM to choose a more advanced DS. But I don't have a lot of faith that the LLM will get said DS right all the time.
I work with dynamic language developers. Perl, React, Python and so on. Most currently don't care about memory usage. Some devs are actively wasteful. Usually in the name of code clarity or speed of delivery.
I'll tell you why I won't choose it as a solo dev.
Back when I was still young and impressionable, I had several frustrating experiences with it at university. Most due to my inexperience, a few times due to Windows being Windows. Also, back then the various $$ and time costs. IIRC $125+ for a windows DVD, $150+ for a VS.Net install DVD, and higher hosting prices for Windows. Also, installs and updates OS, .NET, etc were frequent and time consuming. When I'm making $2.50/hr + tips to get by I couldn't afford that kinda investment.
Now, most of my career has been using Linux, and a variety of interpreted languages. I'm comfortable with them. I boot my Windows partition maybe 2 times a year. There would be a huge cost for me to completely transition to .NET.
In order to get me to try it now would require you to show me some set of features that make it a much better choice than what I currently know. For example, if I someday choose to do Windows apps.
I disagree with this, but I understand where it's coming from. I think you have a form of whiplash from things like:
- Novices overusing the new shiny.
- Java/C++/etc Jr programmers overusing design patterns.
- Perl programmers solving everything with regexes.
- Small startups with GraphQL, or any other large enterprise tool.
- Metaprogramming, Maco's, Dependency injection, Recursion, etc when a simpler solution is a better fit.
IMHO, a "best codebase" will be just a bit more advanced than I am, with good resources for me to grok it. I want to be able to learn from it. I also don't want to be so far out of my depth that I can't make a reasonable contribution.
I work with a client that has us ssh in. We are committing on branches, and they are linked to testing subdomains. So there is some safety. In theory you can spin up a local copy. Almost no one does it. Between the micro services, needing to copy multiple SQL schemas, and seed it with test data, there are a lot of hurdles with little reward.
For my personal sites, one is just a scp, into a subdir. If everything looks good, I just mv it to overwrite live. The other I just restart the process. There's nothing "mission critical" on it.
Around 2010 the company I worked for had a pay freeze. Most employees worked in the office, but about 1/4 worked remote. About three years later the freeze was lifted. The in office employees were notified about said policy change and got raises shortly thereafter. Us remote employees didn't know about the change until almost 2 years later. After an in office employee mentioned it to one of us.
When we brought it up to management they were apologetic, and said they forgot. I work for a small company that wasn't particularly organized so it's possible they forgot but still. :(
TL;DR; If you take the pay cut, check in every few months with both management and others at your level.
Stop giving your employer free labor. It sounds like you're on your way to burnout, and your misplacing some of your frustration onto the Jr devs.
Let me ask you this: What $$ will the current level of work be acceptable? My guess is that it's well above what your employer is willing to pay.
I'd suggest you do what your Jr peels do + 10%, that'll fulfill the requirement for bump & bonus. Also spend some time building relationships. If your manager mentions you no longer doing XYZ, show off your +10%. Politely and tactfully deflect if he tries to press the issue.
To answer your fairness question directly the system sounds inefficient and currently not fair. I think it could be fair(for whatever that means), given the right environment, and attitudes.
Plenty of us coded before SO, but I think you're being too general. Using SO to see examples of syntax is completely different than copying a chunk/function/page of original code someone wrote to solve a problem.
While I agree businesses have to mitigate against bots and hacking, I'd like to push back a bit. I'm an American living abroad. I have the same types of issues as OP, even with my reliable internet. The current methods of mitigation vary from annoying to outright discriminatory.
One example is that my home state's IRS portal(along with all the other state gov sites) straight up block access from the overseas democracy I live in. I assume they block almost all overseas access but I haven't tried to verify it. Like OP, I need to use a SOCKS proxy, or VPN to bypass this heavy handed tactic. While I'd love for it to not be so, Americans living abroad still have to file their taxes. An NPR article said there's probably close to 5 million of us expats.
Lastly with the Cloud VMs, it doesn't seem that this sort of ban is evenly distributed. I've proxied/tunneled through Linode, a well known Torrent VPN, and Digital Ocean, without raising any red flags, but Amazon, ViperVPN, and NordVPN have been flagged. I could go on and argue that with the learn to code movement I could see a cloud instance being the new geocities homepage, but that may never come to pass.
Some of the comments below are talking about how to successfully argue against the move. Does your company have some history you can point out? We've had enough of these type guys and their failed space ship projects that any proposal for a language shift, or major framework adoption is viewed with skepticism first.
We've dealt with "new guy wants to overhaul ..." scenario. When I joined this company we were a C++ shop with some Perl and bash. Multiple new recruits successfully lobbied to implement refactors, or new projects in a hot language/framework. Several of the refactors were a huge waste of resources that either didn't come to fruition, or were only partially successful.
Now, we are a Perl shop with active development in 3 other languages(not counting front end), and we're maintaining legacy apps in an additional 4 languages. And we've deprecated apps in at least 3 additional languages.
I guess I should be thankful none of them have lobbied for switching databases. :-O On any given year, we average 3-4 programmers and 2-4 contractors(mostly front end) Two of us have been there 15+ years, but the other full timers seem to move on around the three year mark. Because of that all the hot shots have left. When a major bug is discovered in their code it can take a long time to fix, and any breakage due to upgrades is quite a hassle since those of us left aren't experts at every language we have to maintain.
> Also, what's up with people asking this question in the first conversation?
At least here in the USA, there's a lot of advice about deflecting that question. Things like, countering with "What are your pay ranges?", or "Let's wait to negotiate the salary until we're sure we're a good fit." and so on.
I believe the common reasoning that they ask early is to cut out overpriced developers. When a company gets lots of applicants this probably makes sense to them. I think generally, if you're a good fit they'll go a little above their max pay to try and bring you in.
If I understand right you are saying that the # of symbols Perl employs makes it hard to understand or read, correct?
TL;DR; I would say that you assertion is context sensitive.
- For a junior Perl programmer or an outside expert those symbols are stumbling blocks.
- For an intermediate Perl programmer and up, those symbols are tools that make the code more readable and expressive.
I got two ways of looking at that. First, I would look at Perl in the context of language. It is a more context sensitive language than some of it's close competitors. When you understand those \ $ % @ & sigils you gain the ability to know at a glance the context in which data is being used. Understanding @_, $_, allows you to write shorter code without sacrificing meaning. Part of the Perl philosophy is TIMTOWTDI. Most of those special variables also have an English equivalent. Instead of using $) which I never remember I can use $EGID, or if I think that's not explicit enough then I can use $EFFECTIVE_GROUP_ID to really spell it out.
The second way is that Perl has a steeper learning curve than it's close competitors. I see this like comparing Vim to Notepad++ and Emacs, or Haskell to well most other functional programming languages. Just because it took longer to learn, that doesn't mean it's better or worse at creating good code. It does mean that armchair pundits are less likely to be correct in their hot takes. They lack experience and understanding.
I agree with this threshold idea, and I would argue that Perl and probably Ruby also have a lower threshold for switching than Python. Nothing against Python.
This is something I plan to start writing about. There isn't enough intermediate and advanced material. I've also ran into too many "senior" programmers that not only lack some of the topics you mentioned, but also fail to grasp the importance of structural things that would improve overall code quality.
How's that saying go? Show me a programmer with 20 years experience, and I'll show you a programmer that did the same thing twenty years in a row.
When we traveled(2015-2018):
- laptop, no larger than 17 in screen, and the thinner and lighter the better.
- portable monitor like the Asus ZenScreen MB14AC
- VPN
- universal power adapters & a surge protector
- small mouse & small keyboard like the Logitech K380
Most of my Digital Nomading has been outside the USA in Europe & Asia. We stayed between several weeks to several months per location. Internet experiences, and requirements will vary country by country but as long as you stay in or near a large metropolitan area you can expect fast internet. The the only exception so far has been China, theirs was slow no matter where I went.
I always tried to make my personal hotspot(Google Fi) the last resort. I used a local hotspot, AirBNB/Cafe WiFi, and coworking spaces as must as possible. Also, for video conferencing, I'd lower streaming quality. No one needs to see my ugly mug in that high a resolution. VPN was not for video conferencing, or browsing reddit/HN. It was mostly for interacting with financial institutions, and transferring IP back and forth with work. It's up to you on how paranoid you wanna be.
There's a whole bunch of technical skills that Universities didn't teach when I was there. I would recommend reading The Pragmatic Programmers by David Thomas and Andrew Hunt to help with that.
Equally important are your soft skills. I would recommend reading The Hard Truth About Soft Skills: Workplace Lessons Smart People Wish They'd Learned Sooner by Peggy Klaus.
I work for a small company that's been around for 20+ years. All of those things you outlined as basic, are things that I have been fighting for the last eight years. I've won a few battles, compromised on a few others, but lost most.
In my opinion your expectations are too high for a small company. Most of the people I have worked with at small companies don't have experience with most those basic tools. Some actively are afraid of code reviews, and others see tests as writing the same code twice, hence a waste of time.
Management and coworkers pay lip service to wanting these things, but I've found that they see them as nice to have extras, and not as time saving efficiency increasing tools.
Don't get me wrong things can change. One way I found is to overwork myself and implement it outside of my normal projects. Then I just have to keep pushing and educating people to follow along. That's how I got the majority of our code under revision control.
The other way is that management finally has enough of a problem and someone convinces them one of those basics will make things better. In our case managment got tired of making new features live, and finding out afterwards that something else had regressed. That's how we got end-to-end tests.
Company culture can change, but it'll be slow. Try and frame things in a cost-benefit light for management. For developers try and show them how it will make their life easier, and show them the cool factor. Good Luck!
To each their own. It always fascinates me to hear about Java/.NET environments that massive. Do you only work on 1 project for months at a time? Do you not ever need to reboot into another OS? Is your laptop power efficient? Do you have a separate machine just for Gaming?
I mostly program in languages like Ruby & Perl using Vim. Even with my decked out version that has 35 plugins, and some other bells and whistles, I'm on average using 20 MB of RAM. Open/Close is near instantaneous.
We shouldn't compare creation of languages to frameworks. If you look at back end frameworks, like web MVCs or ORMs, each language usually only has one or two major players.
I work with dynamic language developers. Perl, React, Python and so on. Most currently don't care about memory usage. Some devs are actively wasteful. Usually in the name of code clarity or speed of delivery.